OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

kmip message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


As requested in today’s call, I am posting this email to explain my proposed amendment to Section 2.2 of the proposed HTTPS profile document. I have attached emails from Tim Hudson, Bob Lockhart and myself as background.

 

The HTTPS profile proposal currently allows the HTTPS service to listen on any port, including 5696. However, if port 5696 is used for HTTPS, then it also requires that KMIP/TTLV be supported by the server, and that KMIP/TTLV must be supported on port 5696 at the same time.

 

My proposed amendment (see email below) removes the requirement to support both HTTPS and KMIP/TTLV on port 5696 at the same time, when a user elects to configure HTTPS on port 5696.

 

If I correctly understand Tim’s reason (see * below) for requiring KMIP/TTLV on 5696 when KMIP/HTTPS is used on 5696, it is that IANA has assigned port 5696 for KMIP/TTLV, and therefore if 5696 is used (for anything), it must also support KMIP/TTLV. This reasoning is just plain wrong because the same logic would require that a KMIP server support SMTP on port 25 if a KMIP server was configured to use port 25 for KMIP/TTLV, SSH on port 22 if a KMIP server was configured to use port 22 for KMIP/TTLV, Telnet on port 23 if a KMIP server was configured to use port 23 for KMIP/TTLV, etc.

 

I also think it is a dangerous precedent to require support of KMIP/TTLV on port 5696 in a profile document when the KMIP standard itself does not require the service to run on that port – even if (or especially if) this compulsion is a conditional one.

 

I think that port assignments are end user issues, not something that should be forced onto end users. We have been allocated port 5696 by IANA for KMIP. That does not mean a user has to use it, just like there is no compulsion for a user to use port 80 for HTTP, 443 for HTTPS, 22 for SSH, 23 for Telnet, etc.

 

John

 

* From attached email sent by Tim: “The reason for requiring that TTLV is supported is that TCP port 5696 is registered for OASIS KMIP and that means the TTLV encoding and not HTTPS as HTTPS is not in the specification. This basically requires that TTLV is supported if you are using the port that is defined for that protocol but also allows the server to support the HTTPS profile in addition - but disallows the use of port 5696 for only HTTPS.”

 

 

From: kmip@lists.oasis-open.org [mailto:kmip@lists.oasis-open.org] On Behalf Of John Leiseboer
Sent: Monday, 2 July 2012 3:21 PM
To: Tim Hudson; kmip@lists.oasis-open.org
Subject: RE: [kmip] Groups - kmip-https-profile-v1.0-wd04.pdf uploaded

 

> Submitter's message
> Updated draft including test case (using test case 12.1).
> Applied comments from other TC members.
> -- Tim Hudson

 

"2.2 KMIP Port Number

KMIP servers conformant to this profile MAY use TCP port number 5696, as assigned by IANA, to receive and send KMIP messages provided that both HTTP and non-HTTP encoded messages are supported."

 

What’s the reason for requiring both message formats if TCP port 5696 is used?

 

Why not allow both message formats to use the same port number without making it mandatory?

 

Suggested replacement text:

"2.2 KMIP Port Number

KMIP servers conformant to this profile MAY use TCP port number 5696, as assigned by IANA, to receive and send KMIP messages provided that both HTTP and non-HTTP encoded messages are supported."

 

John Leiseboer

 

--- Begin Message ---
On 2/07/2012 3:21 PM, John Leiseboer wrote:

> Submitter's message
> Updated draft including test case (using test case 12.1).
> Applied comments from other TC members.
> -- Tim Hudson

 

"2.2 KMIP Port Number

KMIP servers conformant to this profile MAY use TCP port number 5696, as assigned by IANA, to receive and send KMIP messages provided that both HTTP and non-HTTP encoded messages are supported."

 

What’s the reason for requiring both message formats if TCP port 5696 is used?

 

Why not allow both message formats to use the same port number without making it mandatory?

 

Suggested replacement text:

"2.2 KMIP Port Number

KMIP servers conformant to this profile MAY use TCP port number 5696, as assigned by IANA, to receive and send KMIP messages provided that both HTTP and non-HTTP encoded messages are supported."

 

John Leiseboer

 


Thanks for the feedback.

The reason for requiring that TTLV is supported is that TCP port 5696 is registered for OASIS KMIP and that means the TTLV encoding and not HTTPS as HTTPS is not in the specification. This basically requires that TTLV is supported if you are using the port that is defined for that protocol but also allows the server to support the HTTPS profile in addition - but disallows the use of port 5696 for only HTTPS.

That matches the previous discussions on this profile and the discussions around the IANA port allocation.

Thanks,
Tim.


--- End Message ---
--- Begin Message ---

> The reason for requiring that TTLV is supported is that TCP port 5696

> is registered for OASIS KMIP and that means the TTLV encoding and not

> HTTPS as HTTPS is not in the specification. This basically requires

> that TTLV is supported if you are using the port that is defined for

> that protocol but also allows the server to support the HTTPS profile

> in addition - but disallows the use of port 5696 for only HTTPS.

Thanks for the explanation. But I don’t understand where “disallows the use of port 5696 for only HTTPS” comes from (other than in the proposed HTTPS profile document).

 

Who disallows port 5696 for KMIP/TTLV/HTTP/TLS? Surely not IANA. Port 5696 is recommended but not required for KMIP/TTLV/TLS in the KMIP standard.

 

What would happen in future with, for example, KMIP/JSON/TLS, KMIP/XML/TLS, KMIP/JSON/HTTP/TLS, KMIP/TTLV/TCP/IPSEC, etc.? Would these all be disallowed from using port 5696 unless KMIP/TTLV/TLS was also running on port 5696?

 

John

 

From: Tim Hudson [mailto:tjh@cryptsoft.com]
Sent: Monday, 2 July 2012 3:55 PM
To: John Leiseboer
Cc: kmip@lists.oasis-open.org
Subject: Re: [kmip] Groups - kmip-https-profile-v1.0-wd04.pdf uploaded

 

On 2/07/2012 3:21 PM, John Leiseboer wrote:

> Submitter's message
> Updated draft including test case (using test case 12.1).
> Applied comments from other TC members.
> -- Tim Hudson

 

"2.2 KMIP Port Number

KMIP servers conformant to this profile MAY use TCP port number 5696, as assigned by IANA, to receive and send KMIP messages provided that both HTTP and non-HTTP encoded messages are supported."

 

What’s the reason for requiring both message formats if TCP port 5696 is used?

 

Why not allow both message formats to use the same port number without making it mandatory?

 

Suggested replacement text:

"2.2 KMIP Port Number

KMIP servers conformant to this profile MAY use TCP port number 5696, as assigned by IANA, to receive and send KMIP messages provided that both HTTP and non-HTTP encoded messages are supported."

 

John Leiseboer

 


Thanks for the feedback.

The reason for requiring that TTLV is supported is that TCP port 5696 is registered for OASIS KMIP and that means the TTLV encoding and not HTTPS as HTTPS is not in the specification. This basically requires that TTLV is supported if you are using the port that is defined for that protocol but also allows the server to support the HTTPS profile in addition - but disallows the use of port 5696 for only HTTPS.

That matches the previous discussions on this profile and the discussions around the IANA port allocation.

Thanks,
Tim.


--- End Message ---
--- Begin Message ---
On 2/07/2012 4:54 PM, John Leiseboer wrote:
Who disallows port 5696 for KMIP/TTLV/HTTP/TLS? Surely not IANA. Port 5696 is recommended but not required for KMIP/TTLV/TLS in the KMIP standard.

Port 5696 is registered with IANA for kmip and that means registered for what is in the official specification and hence the TTLV encoding.
Suggesting using 5696 for something other than the encoding defined would be like running KMIP on port 25 instead of SMTP - you can of course technically do that however that isn't what a client would expect.

Having been the lucky person that was selected to answer the various technical questions from IANA on the port allocation I'm quite familiar with their views on such things.

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. If you elect to not support TTLV then you will impact interoperability - and as the purpose of KMIP is interoperability and each time we have looked at an issue the direction we have taken is to err on the side of what will help ensure interoperability is the result.

For reference, some vendors operate on port 5696, some on 443, some on both, and some on an entirely different port.

Naturally enough you can elect to ignore the conformance statements in the specification, the profile, and this document too but in doing so you cannot claim conformance as that requires implementing and supporting each of the mandatory statements in each of the documents.

Thanks,
Tim.


--- End Message ---
--- Begin Message ---

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


--- End Message ---
--- Begin Message ---
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

---------------------------------------------------------------------
To unsubscribe, e-mail: kmip-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: kmip-help@lists.oasis-open.org



--- End Message ---
--- Begin Message ---
On 4/07/2012 4:40 AM, Lockhart, Robert wrote:
> 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).

https://www.oasis-open.org/committees/download.php/33403/UG%20Proposal%20-%20KMIP_HTTPS.pdf

Back in July 2009 - so three years back - and this was the starting
point for the current proposal. Alan's original ideas and the various
feedback items and discussions from then along with the feedback we got
when we queried this again before the 1.0 committee specification vote
and the feedback provided since we proposed the separate profile
following the new format for profiles back in April are what led to the
current proposal and its wording.

Tim.



---------------------------------------------------------------------
To unsubscribe, e-mail: kmip-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: kmip-help@lists.oasis-open.org



--- End Message ---


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]