RE: [kmip] Groups - kmip-https-profile-v1.0-wd04.pdf uploaded

["Lockhart, Robert" <Robert.Lockhart@thalesesec.com>]

Personally I believe that this wanders too far into vendor specific implementations.  There is no reason that a vendor cannot associate the two services on a common port in this case as long as they can separate the messages on the backend to get it to the proper interpreter.  Some day we might get that second port and this would be a good use of it.  Until then it should only be a recommendation and not a requirements.

The reason I see this as vendor specific implementation is that port assignment to something other than the standard port is totally up to the end user based on their requirements and thus out of scope of any of our profiles to lock into a specific port unless there are dire consequenses associated with moving the port.  Having said that, because KMIP using TTLV over TLS is assigned courtesy of IANA port 5696 as the default port, just make sure the profile spells out that it is the default port for TTLV and that HTTPS posts have a default port sitting at 443 but either can be reassigned as long as the devices support the default ports out of the box (TTLV using HTTPS posts using TCP port 443 & TTLV over TLS using port 5696).

If a server vendor only wants to run KMIP TTLV over HTTPS post and not regular TTLV over plain TLS then there is no reason the server should have to use anything other than the assigned port until we either get a second port (preferred)or kill the idea altogether to remove any confusion it may cause.  The fact is that while a profile is in place a vendor doesn't have to support all of it if they choose not to.  They just can't claim Profile conformance if that is the case.

If memory serves me correctly the original interop used HTTPS posts in order to propose KMIP to OASIS to begin with (someone want to remind me?).  I thought we had always planned to bring it back (or so I thought).

Bob L.

Robert A. (Bob) Lockhart
Chief Solution Architect - Key Management
THALES e-Security, Inc.
-------------------------------------------------------
W:     www.thales-esecurity.com<http://www.thales-esecurity.com/>
________________________________
From: kmip@lists.oasis-open.org [kmip@lists.oasis-open.org] On Behalf Of John Leiseboer [jl@quintessencelabs.com]
Sent: Monday, July 02, 2012 01:35
To: Tim Hudson
Cc: kmip@lists.oasis-open.org
Subject: RE: [kmip] Groups - kmip-https-profile-v1.0-wd04.pdf uploaded

Port 5696 is registered with IANA for kmip and that means registered for what is in the official specification and hence the TTLV encoding.
Although IANA assigns port numbers, they are not binding. There is no IANA police force. No doubt, when offering an open, public, or cloud service, then it makes lots of sense to use the IANA assigned port for that service. However, there are many organisations – including those providing a service for third party access – that do not use IANA assigned ports. Many of those organisations (and I have spoken to plenty of them), have policies in place to ensure that (some) assigned ports are not used “for security reasons”, and/or “ease of administration”.

Suggesting using 5696 for something other than the encoding defined would be like running KMIP on port 25 instead of SMTP
No. It’s more like using port 25 for SMTP/HTTP. Not good for open, public interop, but works just fine for cooperating peers.

you can of course technically do that however that isn't what a client would expect.
Using this reasoning, KMIP/TTLV/HTTP/TLS should not use port 5696 either – whether or not KMIP/TTLV/TLS uses 5696. I don’t understand why the proposal allows KMIP/TTLV/HTTP/TLS on port 5696 as long as KMIP/TTLV/TLS also uses 5696, but disallows it otherwise. If 5696 is not the “right” port for KMIP/TTLV/HTTP/TLS, then why allow it all? If it is okay, then why require KMIP/TTLV/TLS to also use the exact same port at the same time on the same server?

From a pragmatic point of view, if you offer services on port 5696 you really need to ensure that the server on that port will respond in a manner that a client using the officially registered port would expect.
Not necessarily. For public access to the service it makes sense. But as I said above, there are many organisations that purposely do not allow this. And for some services in fact, they put policies in place to specifically disallow use of the assigned port. (Isn’t this also the main reason for this profile – organisations not providing access to port 5696?)

If you elect to not support TTLV then you will impact interoperability
No. If you elect not to use port 5696 then you will impact interoperability. So let’s carry KMIP through a port that’s usually open, say port 443, and lets ensure that we wrap KMIP in a protocol that can get through proxies, and firewalls, say HTTPS. This makes sense. Why complicate it with rules on combinations of protocols and port number usage?

If you elect to not support TTLV then you will impact interoperability
At no time have I said that TTLV should not, or would not be supported. I am trying to understand what the compelling reason is for forcing all implementations of this profile that want to use port 5696 (for whatever reason – it’s not my business to direct customers’ policies), to also concurrently support KMIP/TTLV on the same port. (For the record, I have no problem with allowing this. The QLab’s server will do this when we get around to coding it. My concern is forcing this behaviour on all implementations and all end users by making it a requirement.)

Naturally enough you can elect to ignore the conformance statements in the specification, the profile, and this document
It is only this proposal that forces the issue of having to support KMIP/TTLV/TLS on port 5696 if 5696 is also used for KMIP/TTLV/HTTP/TLS. There is no other KMIP document that would deem an implementation non-compliant if KMIP/TTLV/TLS uses a port other than 5696. If the aim is to force KMIP implementations to use port 5696, then that should be made a requirement in the KMIP specification, not as a side effect of configuring the port for the HTTPS profile.

John