Re: Fourth Last Call: draft-housley-tls-authz-extns
At 08:18 14-01-2009, The IESG wrote: The IESG is considering approving this draft as a standards track RFC. The IESG solicits final comments on whether the IETF community has consensus to publish draft-housley-tls-authz-extns as a proposed standard. Comments can be sent to ietf@ietf.org or exceptionally to The latest IPR disclosure posted since the third Last-Call does not require any license for implementors. However, there are constraints on the the use of the technique specified in draft-housley-tls-authz-extns-07. This draft has been a matter of discussion since June 27, 2006. It is nearly three years and yet there still isn't any implementation available or any deployment. Because of the lack of implementation and the narrow use that can be made of the technique described in the draft, it is my view that it doesn't warrant publication on the Standards Track. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Fourth Last Call: draft-housley-tls-authz-extns
I do not support publication of this document as a Proposed Standard via the AD-sponsored route, for several reasons: a. I believe that this document should have been handled as a WG work item. It should not be commonplace for standards track security documents to be handled outside of a WG. This issue has been addressed in IPsec (via IPSECME), and TLS needs to follow suit. If the TLS WG does not wish to deal with this and other documents, then the IETF should considered formation of a new WG. b. This document has become a lightening rod for attacks on the integrity of the IETF and IESG. While many of these attacks are groundless, proceeding with the approval of this document without addressing the underlying problems would send the wrong message about the IETF's commitment to ethics. -Original Message- From: ietf-announce-bounces at ietf.org [mailto:ietf-announce-bounces at ietf.org] On Behalf Of The IESG Sent: 14 January 2009 16:18 To: IETF-Announce Subject: Fourth Last Call: draft-housley-tls-authz-extns On June 27, 2006, the IESG approved Transport Layer Security (TLS) Authorization Extensions, (draft-housley-tls-authz-extns) as a proposed standard. On November 29, 2006, Redphone Security (with whom Mark Brown, a co-author of the draft is affiliated) filed IETF IPR disclosure 767. Because of the timing of the IPR Disclosure, the IESG withdrew its approval of draft-housley-tls-authz-extns. A second IETF Last Call was initiated to determine whether the IETF community still had consensus to publish draft-housley-tls-authz-extns as a proposed standard given the IPR claimed. Consensus to publish as a standards track document was not demonstrated, and the document was withdrawn from IESG consideration. A third IETF Last Call was initiated to determine whether the IETF community had consensus to publish draft-housley-tls-authz-extns as an experimental track RFC with knowledge of the IPR disclosure from Redphone Security. Consensus to publish as experimental was not demonstrated; a substantial segment of the community objected to publication on any track in light of the IPR terms. Since the third Last Call, RedPhone Security filed IETF IPR disclosure 1026. This disclosure statement asserts in part that the techniques for sending and receiving authorizations defined in TLS Authorizations Extensions (version draft-housley-tls-authz-extns-07.txt) do not infringe upon RedPhone Security's intellectual property rights. The full text of IPR disclosure 1026 is available at: https://datatracker.ietf.org/ipr/1026/ This Last Call is intended to determine whether the IETF community had consensus to publish draft-housley-tls-authz-extns as a proposed standard given IPR Disclosure 1026. The IESG is considering approving this draft as a standards track RFC. The IESG solicits final comments on whether the IETF community has consensus to publish draft-housley-tls-authz-extns as a proposed standard. Comments can be sent to ietf at ietf.org or exceptionally to iesg at ietf.org. Comments should be sent by 2009-02-11. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-housley-tls-authz-extns-07.txt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
I do not support publication of this document as a Proposed Standard, for several reasons: a. I believe that the subject of this document (TLS authorization) is of fundamental importance to a number of IETF WGs, and therefore it should not be handled via AD-sponsorship, but rather within a WG. If the TLS WG does not wish to deal with the document, then the IETF should consider formation of a new WG to deal with this and other TLS extensions. b. This document has become a lightening rod for attacks on the integrity of the IETF and IESG. Rather than ignoring the concerns that have been raised, I believe that the IETF needs to tackle them head on, by initiating reforms in the areas of affiliation disclosure and conflict of interest within the IESG. Given the current controversy, approving this document could be interpretted as a lack of concern about those issues. c. I'm not convinced that the latest Redphone IPR disclosure represents a substantive rather than a cosmetic change from previous disclosures. -Original Message- From: ietf-announce-bounces at ietf.org [mailto:ietf-announce-bounces at ietf.org] On Behalf Of The IESG Sent: 14 January 2009 16:18 To: IETF-Announce Subject: Fourth Last Call: draft-housley-tls-authz-extns On June 27, 2006, the IESG approved Transport Layer Security (TLS) Authorization Extensions, (draft-housley-tls-authz-extns) as a proposed standard. On November 29, 2006, Redphone Security (with whom Mark Brown, a co-author of the draft is affiliated) filed IETF IPR disclosure 767. Because of the timing of the IPR Disclosure, the IESG withdrew its approval of draft-housley-tls-authz-extns. A second IETF Last Call was initiated to determine whether the IETF community still had consensus to publish draft-housley-tls-authz-extns as a proposed standard given the IPR claimed. Consensus to publish as a standards track document was not demonstrated, and the document was withdrawn from IESG consideration. A third IETF Last Call was initiated to determine whether the IETF community had consensus to publish draft-housley-tls-authz-extns as an experimental track RFC with knowledge of the IPR disclosure from Redphone Security. Consensus to publish as experimental was not demonstrated; a substantial segment of the community objected to publication on any track in light of the IPR terms. Since the third Last Call, RedPhone Security filed IETF IPR disclosure 1026. This disclosure statement asserts in part that the techniques for sending and receiving authorizations defined in TLS Authorizations Extensions (version draft-housley-tls-authz-extns-07.txt) do not infringe upon RedPhone Security's intellectual property rights. The full text of IPR disclosure 1026 is available at: https://datatracker.ietf.org/ipr/1026/ This Last Call is intended to determine whether the IETF community had consensus to publish draft-housley-tls-authz-extns as a proposed standard given IPR Disclosure 1026. The IESG is considering approving this draft as a standards track RFC. The IESG solicits final comments on whether the IETF community has consensus to publish draft-housley-tls-authz-extns as a proposed standard. Comments can be sent to ietf at ietf.org or exceptionally to iesg at ietf.org. Comments should be sent by 2009-02-11. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-housley-tls-authz-extns-07.txt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
I'm writing to ask you not to approve the proposed patent-encumbered
standard for TLS authorization.
We've achieved a massive technological progress, thanks to IETF and
other bodies which strive for standardization of OPEN specifications.
Allowing a patent-encumbered (without a non-revokable royalty-free
license) standard to be approved, will weaken not only the IETF, but
the open standards community as a whole.
I urge the IETF to send a strong signal in support of TRUE OPEN
STANDARDS by rejecting this proposed standard until RedPhone provide a
non-revokable, royalty-free license for all users.
Thanks,
Pablo Kohan
--
___
| Pablo 'merKur' Kohan \ \ /|
| Founder, CEO \ \/To bring IN-OVATION turn to |
| mailto:pa...@ximpo.com /\ \ your open source of solutions |
| Phone: +972-54-422-5371/ \ \|
| Fax:+972-50-681-1928 http://www.ximpo.com/ |
|__ Ximpo Group _|
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
RE: Fourth Last Call: draft-housley-tls-authz-extns
This standard should be wholly withdrawn until all patent encumberances are fully removed. GNU's statement summarizes it well: http://www.fsf.org/news/reoppose-tls-authz-standard Much of the communication on the Internet happens between computers according to standards that define common languages. If we are going to live in a free world using free software, our software must be allowed to speak these languages. Unfortunately, discussions about possible new standards are tempting opportunities for people who would prefer to profit by extending proprietary control over our communities. If someone holds a software patent on a technique that a programmer or user has to use in order to make use of a standard, then no one is free without getting permission from and paying the patent holder. If we are not careful, standards can become major barriers to computer users having and exercising their freedom. We depend on organizations like the Internet Engineering Task Force (IETF) and the Internet Engineering Steering Group (IESG) to evaluate new proposals for standards and make sure that they are not encumbered by patents or any other sort of restriction that would prevent free software users and programmers from participating in the world they define. In February 2006, a standard for TLS authorization was introduced in the IETF for consideration. Very late in the discussion, a company called RedPhone Security disclosed (this disclosure has subsequently been unpublished from the IETF website) that they applied for a patent which would need to be licensed to anyone wanting to practice the standard. After this disclosure, the proposal was rejected. Despite claims that RedPhone have offered a license for implementation of this protocol, users of this protocol would still be threatened by the patent. The IETF should continue to oppose this standard until RedPhone provide a royalty-free license for all users. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
The IESG iesg-secret...@ietf.org writes: Since the third Last Call, RedPhone Security filed IETF IPR disclosure 1026. This disclosure statement asserts in part that the techniques for sending and receiving authorizations defined in TLS Authorizations Extensions (version draft-housley-tls-authz-extns-07.txt) do not infringe upon RedPhone Security's intellectual property rights. The full text of IPR disclosure 1026 is available at: https://datatracker.ietf.org/ipr/1026/ This Last Call is intended to determine whether the IETF community had consensus to publish draft-housley-tls-authz-extns as a proposed standard given IPR Disclosure 1026. Given the patent disclaimer from RedPhone, I'm against publishing this as a proposed standard. It seems no license is demanded to implement the technology, which is a step in the right direction. It also seems clear that RedPhone will demand a license for _use_ of the technology. Practical use-cases appears to be covered by this demand. That makes the technology unsuitable as a proposed standard to me. I am also concerned that the earlier patent disclaimer #765 is not available: https://datatracker.ietf.org/ipr/765/ This makes it impossible for the community to review the history around the licensing conditions. This seems contrary to the requirements of RFC 3979 aka BCP 0079: Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. Thus it seems the policies around patent disclosures have not been followed by the IETF itself here. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
I share the concerns of the FSF [http://www.fsf.org/news/reoppose-tls-authz-standard] and Simon Josefsson [http://www.ietf.org/mail-archive/web/ietf/current/msg55059.html] about the TLS-authz draft. The usefulness of the proposed standard http://tools.ietf.org/id/draft-housley-tls-authz-extns-07.txt appears to be severely limited by the patent disclosed in https://datatracker.ietf.org/ipr/1026/. For example, if the authorization is intended to play a role in the enforcement or implementation of any legally recognizable and documented agreement between two parties, then RedPhone Security apparently asserts patent infringement in their IPR. The offer of fair and nondiscriminatory license grants is unclear, but similar offers in the past have excluded use in free software. Please continue to oppose this standard until RedPhone's patent is invalidated or they provide a royalty-free license for all users. Sean Foy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Fourth Last Call: draft-housley-tls-authz-extns
I support publication of this document. josh. -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG Sent: 14 January 2009 16:18 To: IETF-Announce Subject: Fourth Last Call: draft-housley-tls-authz-extns On June 27, 2006, the IESG approved Transport Layer Security (TLS) Authorization Extensions, (draft-housley-tls-authz-extns) as a proposed standard. On November 29, 2006, Redphone Security (with whom Mark Brown, a co-author of the draft is affiliated) filed IETF IPR disclosure 767. Because of the timing of the IPR Disclosure, the IESG withdrew its approval of draft-housley-tls-authz-extns. A second IETF Last Call was initiated to determine whether the IETF community still had consensus to publish draft-housley-tls-authz-extns as a proposed standard given the IPR claimed. Consensus to publish as a standards track document was not demonstrated, and the document was withdrawn from IESG consideration. A third IETF Last Call was initiated to determine whether the IETF community had consensus to publish draft-housley-tls-authz-extns as an experimental track RFC with knowledge of the IPR disclosure from Redphone Security. Consensus to publish as experimental was not demonstrated; a substantial segment of the community objected to publication on any track in light of the IPR terms. Since the third Last Call, RedPhone Security filed IETF IPR disclosure 1026. This disclosure statement asserts in part that the techniques for sending and receiving authorizations defined in TLS Authorizations Extensions (version draft-housley-tls-authz-extns-07.txt) do not infringe upon RedPhone Security's intellectual property rights. The full text of IPR disclosure 1026 is available at: https://datatracker.ietf.org/ipr/1026/ This Last Call is intended to determine whether the IETF community had consensus to publish draft-housley-tls-authz-extns as a proposed standard given IPR Disclosure 1026. The IESG is considering approving this draft as a standards track RFC. The IESG solicits final comments on whether the IETF community has consensus to publish draft-housley-tls-authz-extns as a proposed standard. Comments can be sent to ietf@ietf.org or exceptionally to i...@ietf.org. Comments should be sent by 2009-02-11. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-housley-tls-authz-ex tns-07.txt ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
Russ Housley hous...@vigilsec.com writes: Simon: For the people who want this draft published (and perhaps have a pending implementation), would you please humour me by offering some usage scenarios, other than debugging or toys, which would meet security review and which are not covered by the four points which the patent-holder notes as potentially encumbered? I'll offer one based on attribute certificates (see RFC 3281). If the attribute certificate policy does not use a critical certificate policy identifier that is within an arc registered to RedPhone Security (e.g. iso.org.dod.internet.private.enterprise.23106), then the most straightforward deployments would not encounter problems with this IPR Statement. RFC 3281 specifies ways to carry access identities, group memberships, roles, and clearances in attribute certificates. As long as these are not coupled to signed agreements such as contracts, as is their normal use, then I cannot see problems with this IPR statement. What's the point of a certificate if you don't ultimately couple it with a contract? Identities, group memberships, roles, and clearances are all attributes defined by non-technical, real-world agreements, often documented in the form of a contract. I can think of many that are not tied to contracts, especially in the manner described in the paragraph numbered 2 in the IPR statement. The authorization data needs to be used to locate the agreement. I've worked with many identification and authorization systems, and this is not a traditional aspect of any of them. I can't think of any realistic complete scenario using RFC 3281, can you describe it? All attribute certificate system I've worked with uses identities that ultimately can be chained back to a legal entity, which will be bound to certain conditions through agreements. The authorization data can thus be used to locate this agreement. Generally, I don't think we should standardize protocols that are known to be encumbered by patents for some applications. I've forwarded the patent disclaimer 1026 to the FSF/SFLC for review by lawyers. I would have felt more comfortable if the patent disclaimer only contained its first paragraph. Right now, it feels like it is saying one (good) thing in the first paragraph. The next paragraphs appears to take away most of the substance by limiting the scope, and using terms that are likely intended to be narrowly scoped but can be read more broadly. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
Simon: For the people who want this draft published (and perhaps have a pending implementation), would you please humour me by offering some usage scenarios, other than debugging or toys, which would meet security review and which are not covered by the four points which the patent-holder notes as potentially encumbered? I'll offer one based on attribute certificates (see RFC 3281). If the attribute certificate policy does not use a critical certificate policy identifier that is within an arc registered to RedPhone Security (e.g. iso.org.dod.internet.private.enterprise.23106), then the most straightforward deployments would not encounter problems with this IPR Statement. RFC 3281 specifies ways to carry access identities, group memberships, roles, and clearances in attribute certificates. As long as these are not coupled to signed agreements such as contracts, as is their normal use, then I cannot see problems with this IPR statement. What's the point of a certificate if you don't ultimately couple it with a contract? Identities, group memberships, roles, and clearances are all attributes defined by non-technical, real-world agreements, often documented in the form of a contract. I can think of many that are not tied to contracts, especially in the manner described in the paragraph numbered 2 in the IPR statement. The authorization data needs to be used to locate the agreement. I've worked with many identification and authorization systems, and this is not a traditional aspect of any of them. I can't think of any realistic complete scenario using RFC 3281, can you describe it? All attribute certificate system I've worked with uses identities that ultimately can be chained back to a legal entity, which will be bound to certain conditions through agreements. The authorization data can thus be used to locate this agreement. Generally, I don't think we should standardize protocols that are known to be encumbered by patents for some applications. I've forwarded the patent disclaimer 1026 to the FSF/SFLC for review by lawyers. I would have felt more comfortable if the patent disclaimer only contained its first paragraph. Right now, it feels like it is saying one (good) thing in the first paragraph. The next paragraphs appears to take away most of the substance by limiting the scope, and using terms that are likely intended to be narrowly scoped but can be read more broadly. There are two parts to your message. I'll try to respond to both. EXAMPLE Clearance may be the easiest one. For simplicity, let's assume that the client are server already have X.509 identity certificates. Assume the server is operated by the military, and it includes some information that its wants to share with the public, perhaps recruiting data, and information that is available to anyone that has a clearance. This latter information is released to any client that presents a valid attribute certificate that is bound to the X.509 identity certificate used in client authentication and issued by any of the military branches that demonstrates that the client holds a clearance. THE IPR STATEMENT I think it was appropriate for RedPhone to provide insight into their patent application. I'm not a lawyer, but the IPR statement is telling the community the ways that this protocol (and It seems to me, any authorization protocol that can has data that can locate agreements) might infringe on the patent application. The major point being that the protocol itself is not be focus of the patent application. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
Russ Housley hous...@vigilsec.com writes: EXAMPLE Clearance may be the easiest one. For simplicity, let's assume that the client are server already have X.509 identity certificates. Assume the server is operated by the military, and it includes some information that its wants to share with the public, perhaps recruiting data, and information that is available to anyone that has a clearance. This latter information is released to any client that presents a valid attribute certificate that is bound to the X.509 identity certificate used in client authentication and issued by any of the military branches that demonstrates that the client holds a clearance. It seems to me that the authorization data passed in this way can be used to locate an agreement, i.e., the legally binding document that approve a certain individual for some clearance level. The 1026 patent disclaimer text suggests this mode would be covered by their patent application. So I don't follow how that would be an example of an unencumbered way to use the protocol? However, this is mostly a legal decision, to evaluate the risks to get sued by implementing the technology, so I'll defer until I understand what a lawyer thinks about the new situation. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
Phil: For the people who want this draft published (and perhaps have a pending implementation), would you please humour me by offering some usage scenarios, other than debugging or toys, which would meet security review and which are not covered by the four points which the patent-holder notes as potentially encumbered? I'll offer one based on attribute certificates (see RFC 3281). If the attribute certificate policy does not use a critical certificate policy identifier that is within an arc registered to RedPhone Security (e.g. iso.org.dod.internet.private.enterprise.23106), then the most straightforward deployments would not encounter problems with this IPR Statement. RFC 3281 specifies ways to carry access identities, group memberships, roles, and clearances in attribute certificates. As long as these are not coupled to signed agreements such as contracts, as is their normal use, then I cannot see problems with this IPR statement. This is one example. I believe there are many more. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
Russ Housley hous...@vigilsec.com writes: Phil: For the people who want this draft published (and perhaps have a pending implementation), would you please humour me by offering some usage scenarios, other than debugging or toys, which would meet security review and which are not covered by the four points which the patent-holder notes as potentially encumbered? I'll offer one based on attribute certificates (see RFC 3281). If the attribute certificate policy does not use a critical certificate policy identifier that is within an arc registered to RedPhone Security (e.g. iso.org.dod.internet.private.enterprise.23106), then the most straightforward deployments would not encounter problems with this IPR Statement. RFC 3281 specifies ways to carry access identities, group memberships, roles, and clearances in attribute certificates. As long as these are not coupled to signed agreements such as contracts, as is their normal use, then I cannot see problems with this IPR statement. What's the point of a certificate if you don't ultimately couple it with a contract? Identities, group memberships, roles, and clearances are all attributes defined by non-technical, real-world agreements, often documented in the form of a contract. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
I had given my +1 a bit early after having seen the techniques for sending and receiving authorizations defined in TLS Authorizations Extensions (version draft-housley-tls-authz-extns-07.txt) do not infringe upon RedPhone Security's intellectual property rights Anyway, there are 4 points in the IPR claim that may require a license. The text is difficult to understand just by taking the text of the ID. The questions raised by others concerning the wording of the 4 points motivate me to step back. Peter ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
Simon: For the people who want this draft published (and perhaps have a pending implementation), would you please humour me by offering some usage scenarios, other than debugging or toys, which would meet security review and which are not covered by the four points which the patent-holder notes as potentially encumbered? I'll offer one based on attribute certificates (see RFC 3281). If the attribute certificate policy does not use a critical certificate policy identifier that is within an arc registered to RedPhone Security (e.g. iso.org.dod.internet.private.enterprise.23106), then the most straightforward deployments would not encounter problems with this IPR Statement. RFC 3281 specifies ways to carry access identities, group memberships, roles, and clearances in attribute certificates. As long as these are not coupled to signed agreements such as contracts, as is their normal use, then I cannot see problems with this IPR statement. What's the point of a certificate if you don't ultimately couple it with a contract? Identities, group memberships, roles, and clearances are all attributes defined by non-technical, real-world agreements, often documented in the form of a contract. I can think of many that are not tied to contracts, especially in the manner described in the paragraph numbered 2 in the IPR statement. The authorization data needs to be used to locate the agreement. I've worked with many identification and authorization systems, and this is not a traditional aspect of any of them. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
I think a standard in this space is really needed. I would definitely like to be able to include SAML assertions and other statements of authorization as part of a TLS exchange. In the appropriate environments I'd be willing to implement this spec given the current IPR situation. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
I think a standard in this space is really needed. Given the revised IPR statement, I think it is clear that it can be implemented widely. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
Sam Hartman wrote: I think a standard in this space is really needed. I would definitely like to be able to include SAML assertions and other statements of authorization as part of a TLS exchange. In the appropriate environments I'd be willing to implement this spec given the current IPR situation. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf +1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
On Jan 14, 2009, at 4:53 PM, Dean Anderson wrote: Somehow I haven't yet recieved the fourth last call, but only the discussion Sigh. see http://www.ietf.org/mail-archive/web/ietf-announce/current/ msg05617.html There are MANY reasons that this should not be brought to a FOURTH last call let me enumerate a few: Obviously I disagree since I did bring it to a fourth last call. I believe the technology is useful, the specification of sufficient quality, and the IPR situation is now consistent with the community's statements in the preceding Last Call. This makes it worth the pain of another last call. 1. --There have been THREE previous, soundly-rejected last calls, the last one with literally dozens, perhaps hundreds of people against it. The first last Call was not rejected at all. It supported publication but was invalidated by the late IPR disclosure. The third Last Call was rather divided, IMHO. And hundreds is a gross exaggeration... 2. --There are a couple of web page on the deception perpetrated by Housley, Brown, Polk et al at http://www.av8.net/IETF-watch/People/Housley/index.html http://www.av8.net/IETF-watch/People/TimPolk/index.html The IETF and IESG positions should not be used to benefit the office-holders through deception of the IETF. The members of the ISOC and participants in the ISOC IETF Activity have clearly rejected the use of IESG seats for this purpose. The allegations are bogus. I am not benefiting in any way, and there has been no deception. There is no attempt to circumvent the community, only an attempt to determine if consensus supports publication given the new IPR disclosure statement. 3. --There have been reports of similar issues in recent lawsuit where the plaintiff patent-holder acted similarly to Housley/Brown/Polk et al and was found to have engaged in aggravated litigation abuse. In that case, the Judge ruled the patents unenforceable as a penalty for the deception of the standards body in that case. (see http://www.ietf.org/mail-archive/web/ipr-wg/current/msg05089.html and http://www.cafc.uscourts.gov/opinions/07-1545.pdf) In my opinion, these cases are irrelevant to the question presently at hand. This last call considers this specification in light of the published IPR disclosure 1026. If this specification is approved and new IPR claims are submitted in the future, then these cases would be relevant. 4. --There is no community consensus to proceed, nor any demand from the community to have this protocol standardized. I would say this is a rather premature consensus call.It's four weeks for individual submissions, not four hours. And I have certainly received email that shows members of the community (other than the authors) want to use this technology. 5. --There is only one implementation: BrownHousley's You know that's not true. Simon Josefsson also implemented authz, although he removed it from his distribution after the initial IPR disclosure. These reasons are sufficient to preclude a standard under the rules of the IETF. Since I disagree with all your reasons, it shouldn't be surprising that I disagree with the conclusion. [stuff deleted, moving onto substantive (IMHO) discussion.] It is also my opinion that there is no need for this subprotocol given the other IETF authorization protocols and standards that would operate transparently inside a TLS channel and need no special TLS handling. There are members of the community that disagree. Some have posted already. But if there is consensus that there is indeed a genuine need to have an authorization sub-protocol as part of TLS, then I believe a new sub-protocol should be developed openly and transparently that does not infringe or utilize Brown's patent, so that Brown, Housley, Polk et al do not profit by the standard. If you read the IPR disclosure statement you will find that this specification does not infringe or utilize RedPhone's IPR. No technical issues have been raised concerning this protocol, and I am not aware of any proposed alternatives. Failure to publish at this point would simply be biting the nose off to spite the face. Tim Polk Dean Anderson CEO AV8 Internet, Inc -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
Dean and the IESG: I will respond to some, but not all of Dean's points. 3. --There have been reports of similar issues in recent lawsuit where the plaintiff patent-holder acted similarly to Housley/Brown/Polk et al and was found to have engaged in aggravated litigation abuse. In that case, the Judge ruled the patents unenforceable as a penalty for the deception of the standards body in that case. (see http://www.ietf.org/mail-archive/web/ipr-wg/current/msg05089.html and http://www.cafc.uscourts.gov/opinions/07-1545.pdf) This case, and at least two others like it, argue the opposite point. Patent claims were placed in the public domain after the court ruled that the patent-holder had not followed the appropriate procedures during development of the standard. In all of the cases that I am aware of, the standards documents were published prior to the courts getting involved. 4. --There is no community consensus to proceed, nor any demand from the community to have this protocol standardized. Several people have asked that this document proceed, including some researchers at Columbia University that want to make use of the protocol. 5. --There is only one implementation: BrownHousley's First, I do not have an implementation. Second, I know that at least one other exists. It was developed for GnuTLS, but it is not being distributed at the moment. It will be interesting to see if the revised IPR statement is sufficient change this situation. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
Dean == Dean Anderson d...@av8.com writes: Dean 3. --There have been reports of similar issues in recent Dean lawsuit where the plaintiff patent-holder acted similarly to Dean Housley/Brown/Polk et al and was found to have engaged in Dean aggravated litigation abuse. In that case, the Judge ruled Dean the patents unenforceable as a penalty for the deception of Dean the standards body in that case. (see Dean http://www.ietf.org/mail-archive/web/ipr-wg/current/msg05089.html Dean and http://www.cafc.uscourts.gov/opinions/07-1545.pdf) Dean, it seems to me that if the patents are not enforceable then there is no impediment to standardization. Help me understand how this is a reason not to publish rather than an argument that Redphone's IPR position is weaker than otherwise expected and thus it might be more reasonable to publish. Dean 4. --There is no community consensus to proceed, nor any Dean demand from the community to have this protocol Dean standardized. I think there is a desire from the community for a solution to the problem that this solved. Didn't Simon work on an implementation before the IPR concerns came up? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fourth Last Call: draft-housley-tls-authz-extns
On 2009-01-14 at 08:18 -0800, The IESG wrote: Since the third Last Call, RedPhone Security filed IETF IPR disclosure 1026. This disclosure statement asserts in part that the techniques for sending and receiving authorizations defined in TLS Authorizations Extensions (version draft-housley-tls-authz-extns-07.txt) do not infringe upon RedPhone Security's intellectual property rights. The full text of IPR disclosure 1026 is available at: https://datatracker.ietf.org/ipr/1026/ I've read through that. So, implementing the part of any useful application which does the protocol encoding/decoding is not encumbered, but doing anything practical with it is? In particular, RedPhone disavow patent encumbrance over sending/receiving but not upon, eg, constructing the authorizations to send or interpreting them; then, they explicitly note cases which may be encumbered, such as looking up the claimed authorizer to ensure that they are in fact permitted to make such an authorization, or using data conveyed in the extension after checking the signature. Either the security policy is statically configured, so a lookup needs to be performed, or the security policy is carried in the TLS transaction and the protocol signatures need to be verified so that arbitrary assertions aren't trusted. I'm not a stake-holder in this and haven't previously contributed, so have no reasonable voice in objecting, but I am trying to understand the situation. It's of little value to be able to send data across the wire if that data is not permitted to convey useful information. For the people who want this draft published (and perhaps have a pending implementation), would you please humour me by offering some usage scenarios, other than debugging or toys, which would meet security review and which are not covered by the four points which the patent-holder notes as potentially encumbered? I'm far from a subject matter expert, so there may well be such cases; I hope that the act of laying out a counter-example or two will make it clearer for all concerned parties what can and can't be done and demonstrate practical use to publication. Thanks, -Phil ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fourth Last Call: draft-housley-tls-authz-extns
On June 27, 2006, the IESG approved Transport Layer Security (TLS) Authorization Extensions, (draft-housley-tls-authz-extns) as a proposed standard. On November 29, 2006, Redphone Security (with whom Mark Brown, a co-author of the draft is affiliated) filed IETF IPR disclosure 767. Because of the timing of the IPR Disclosure, the IESG withdrew its approval of draft-housley-tls-authz-extns. A second IETF Last Call was initiated to determine whether the IETF community still had consensus to publish draft-housley-tls-authz-extns as a proposed standard given the IPR claimed. Consensus to publish as a standards track document was not demonstrated, and the document was withdrawn from IESG consideration. A third IETF Last Call was initiated to determine whether the IETF community had consensus to publish draft-housley-tls-authz-extns as an experimental track RFC with knowledge of the IPR disclosure from Redphone Security. Consensus to publish as experimental was not demonstrated; a substantial segment of the community objected to publication on any track in light of the IPR terms. Since the third Last Call, RedPhone Security filed IETF IPR disclosure 1026. This disclosure statement asserts in part that the techniques for sending and receiving authorizations defined in TLS Authorizations Extensions (version draft-housley-tls-authz-extns-07.txt) do not infringe upon RedPhone Security's intellectual property rights. The full text of IPR disclosure 1026 is available at: https://datatracker.ietf.org/ipr/1026/ This Last Call is intended to determine whether the IETF community had consensus to publish draft-housley-tls-authz-extns as a proposed standard given IPR Disclosure 1026. The IESG is considering approving this draft as a standards track RFC. The IESG solicits final comments on whether the IETF community has consensus to publish draft-housley-tls-authz-extns as a proposed standard. Comments can be sent to i...@ietf.org or exceptionally to i...@ietf.org. Comments should be sent by 2009-02-11. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-housley-tls-authz-extns-07.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
