Subject: Re: Fourth Last Call: draft-housley-tls-authz-extns

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Jan 2009 11:45:37 -0500

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 14 Jan 2009 19:19:16 +0100

> given the current IPR situation.
+1

---

From: Tim Polk <[email-masked]>
Date: Wed, 14 Jan 2009 18:01:06 -0500

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: Brown&Housley'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
>
>
>
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 14 Jan 2009 17:58:31 -0500

Dean and the IESG:

I will respond to some, but not all of Dean's points.

>the plaintiff patent-holder acted similarly to Housley/Brown/Polk et al
>and was found to have engaged in "aggravated litigation abuse". In that

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

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: Brown&Housley'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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 14 Jan 2009 18:40:51 -0500

>>>>> "Dean" == Dean Anderson <[email-masked]> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Phil Pennock <[email-masked]>
Date: Wed, 14 Jan 2009 17:32:44 -0800

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Jan 2009 11:05:05 -0500

>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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 15 Jan 2009 18:11:09 +0100

Russ Housley <[email-masked]> writes:

> I'll offer one based on attribute certificates (see RFC 3281).  If the
> attribute certificate policy does not use a critical certificate
> the most straightforward deployments would not encounter problems with
> this IPR Statement.  RFC 3281 specifies ways to carry access

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

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 15 Jan 2009 18:41:46 +0100

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

---

From: Russ Housley <[email-masked]>
Date: Thu, 15 Jan 2009 14:54:16 -0500

>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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 16 Jan 2009 11:14:05 +0100

Russ Housley <[email-masked]> writes:

> 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

---

From: Russ Housley <[email-masked]>
Date: Fri, 16 Jan 2009 10:44:18 -0500

>using terms that are likely intended to be narrowly scoped but can be

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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 16 Jan 2009 23:36:57 +0100

Russ Housley <[email-masked]> writes:

> 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

---

From: "Josh Howlett" <[email-masked]>
Date: Mon, 19 Jan 2009 14:39:25 -0000

I support publication of this document.

josh. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 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:
> 
> 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 [email-masked] or exceptionally to 
> [email-masked]. 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
> [email-masked]
> 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