Subject: [TLS] Comments on draft-housley-tls-authz-extns-07

From: Eric Rescorla <[email-masked]>
Date: Mon, 28 May 2007 11:38:51 -0700

Folks,

We have a request from the IESG re draft-housley-tls-authz-extns-07.

The IESG is considering publication of this document as a Proposed
Standard. The IESG has requested that the TLS WG provide input
(positive or negative) on this proposal. Please post comments to the
list before Monday June 11.

-Ekr

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 29 May 2007 12:42:30 +0200

> list before Monday June 11.

I implemented tls-authz in gnutls some time ago and sent two technical
comments in <http://thread.gmane.org/gmane.ietf.tls/2365>.  I believe
one of them is still relevant:

- The size of authorization data, i.e., X.509 attribute certs and SAML
  assertions, are limited to 64kb.  Is it certain that we won't need
  more?

Further, as many of you are certainly aware, there are patent claims on
the technology, see the IPR disclosure page at:

https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=833

The disclosure mentions a patent license.  I see two problems with the
license:

1) You need to explicitly request license from RPS.  This approach has
   worked poorly in the past.  Some companies goes away and never
   replies to such requests, leaving implementers in a legally unclear
   situation.  There are even examples of big companies not responding
   to license requests (ObExample: IBM's Unicode BOCU patent license).
   I believe this is sufficient to defer significant wide use of the
   protocol.

   This problem could be addressed by granting the rights in the license
   directly to everyone, without a need to request the license.

2) The license you get restrict use of the protocol to SAML attributes
   and X.509 attribute certificates that do not refer to legal
   contracts.  This is what I have understood 'PAS functions' in the
   license to refer to.  Whether the references must be explicit in the
   authorization data is probably not easy to decide.

   I believe there is a considerable amount of prior art for having
   implicit references to legal contracts in authorization data.  For
   example, a Kerberos ticket with a principal that refer to an
   employee's account can be seen as an implicit reference to the
   employee's contract with the company, which may include a security
   policy that needs to be followed.  Still, existence of prior art
   doesn't mean implementers can ignore a patent.

   For one project I'm involved in which is considering to use
   TLS-AUTHZ, we've informally realized that this situation is a
   non-starter, and that if we have to, we'll look into other technical
   solutions to achieve the same goal as tls-authz.

While I am quite aware of efforts to improve the patent situation -- I
have talked to Mark about the license -- I believe that until there is
consensus in the IETF community that the (possibly revised) license
terms are acceptable for wide deployment on the Internet, this document
should not be published as a Proposed Standard.

/Simon

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 May 2007 15:01:05 -0400

> > We have a request from the IESG re draft-housley-tls-authz-extns-07.

I see many places where authorization will be useful.  I would like 
to see this document get published as a standards track RFC.

I will also reply to Simon's comments.

>   assertions, are limited to 64kb.  Is it certain that we won't need

I recall responding to this the first time around.  I said that I 
could not imagine needing 64KB for X.509 Attribute Certificates, but 
I do not have experience with SAML Assertions.  I know they are 
bigger, but I do not have any way to gauge the likelihood that 64KB 
will not be enough.

>should not be published as a Proposed Standard.

I see many places where authorization will be useful, and in many, if 
not most, of these places the RedPhone Security IPR does not seem to 
apply.  This is my assessment, and I am not a lawyer.  I know that 
the most recent IPR statement from RedPhone Security does not satisfy 
Simon, and I hope that will be resolved in the near future.  Even if 
that turns out to take a long time, the protocol extensions will be 
useful in the contexts where the RedPhone Security IPR does not 
apply., Of course, the applicability must be judged by the 
implementors and users, not by me.

Russ

---

From: Dean Anderson <[email-masked]>
Date: Tue, 29 May 2007 17:12:59 -0400 (EDT)

I believe the IETF announced that it would be sending this draft back to
the 'starting gate'.  To me, that means that TLS has to do several
things:

1) Consider non-patented alternatives in accordance with RFC2418 and
RFC3979.

2) Obtain a thorough review and consensus per RFC2026 and RFC2418.

3) Pass a working group last-call, per RFC2026 and RFC2418.

So, the TLS working group should consider and process the draft as
though it were just now submitted for the first time.

As I understand the IESG position, it is not considering publication at
the present time, and the document is not presently on the IESG agenda,
and will not be on the agenda until a last-call is requested by the TLS
working group chair. If my understanding is not correct, please correct
me.

With the above understanding:

I am against the current draft as it stands on the grounds that it is
patented, and a non-patented alternative is easily found. No
non-patented alternative has been discussed. This is a technical
objection.

Furthermore, I oppose the corrupt acts of the IETF official in
concealing the patent from the IESG while accepting money to write and
promote the draft.  The authors have already admitting to both knowing
of the patent and knowing of the IETF patent policy for the entire
development of the draft, and still concealed the patent from the IESG
and IETF community. A software patent is often worth millions of dollars
for justification of investment capital (that doesn't count the economic
harms, though). A patented software standard is worth many times more.  
The economic motives of the deception are impossible to avoid, and while
this isn't entirely a technical objection [though it is an objection
based on the abuse of IETF process by the authors as permitted by
RFC2026], I think a moral and ethical objection to this draft is quite
appropriate and allowed by RFC2026.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 May 2007 15:19:46 -0700

At Tue, 29 May 2007 17:12:59 -0400 (EDT),
> though it were just now submitted for the first time.

<speaking as chair>

Dean,

That is not correct. This is (and was) an AD sponsored submission.
The TLS WG was previously asked if it wished to take on this document
and said no. The question of whether this document should go back to
ground zero (i.e., as if that discussion had not taken place)
is not really an appropriate one for this group and should be
addressed to the IESG or the IETF mailing list. If you want to
argue that TLS-WG SHOULD take up this kind of work, that is of
course approriate, but it's not a procedural requirement here.

> working group chair. If my understanding is not correct, please correct

This is incorrect. The IESG is now considering publication and it
is in that context that they asked the TLS WG for its opinion.

-Ekr

---

From: "Mark Brown" <[email-masked]>
Date: Tue, 29 May 2007 21:38:19 -0500

A few points I think are relevant:

1) The RedPhone Security (RPS) patent application and its General Use
License (GUL) protect a *new* method of verifying authorizations.

2) If it's been published or in use prior to RPS's patent filing, then *any*
such method of verifying authorizations is "prior art", and can be used with
tls-authz under the GUL.  There are a lot of prior specs in this area...
And of course you're free to invent new verification methods, etc.  Only one
method is reserved by RPS under the GUL.

3) tls-authz doesn't specify any method for verifying authorizations  

The GUL provides a way to be sure that RPS won't raise any claims of
infringement against you (except obviously the PAS functions).  Since nobody
knows precisely which RPS patent claims will issue, executing a GUL may help
to alleviate concerns right now.  The RedPhone Security GUL amounts to a way
to guarantee for yourself that Sending any "prior art" SAML / AC assertions
over TLS will be royalty-free.  On the whole it's your choice to use the GUL
or not.

I'm glossing over some details, but these are the main issues.  I think we
all would benefit from agreeing there is value in authorizing TLS sessions
using assertions, that the tls-authz mechanics are straightforward (and
don't favor RPS IPR), and that using all prior art authorization methods
should be -- and can easily be -- royalty-free under tls-authz and the
RedPhone Security GUL.

--mark

---

From: <[email-masked]>
Date: Wed, 30 May 2007 10:58:39 +0300

Russ Housley wrote:

> >- The size of authorization data, i.e., X.509 attribute 
> >  certs and SAML assertions, are limited to 64kb.  Is it certain 
> >  that we won't need more?
> 
> I recall responding to this the first time around.  I said that 
> I could not imagine needing 64KB for X.509 Attribute Certificates, 
> but I do not have experience with SAML Assertions.  I know they 
> are bigger, but I do not have any way to gauge the likelihood 
> that 64KB will not be enough.

One relatively simple SAML assertion example from the SAML specs 
is 3.5 KB. If it used 4096-bit RSA keys instead of 1024, and 
included holder-of-key SubjectConfirmation block, it would be 
maybe 6 KB. If it included more complex assertions or additional 
certificates, it could get over 10 KB.

IMHO the safety margin is too small for "64K ought to be enough for
everyone" :-)

Best regards,
Pasi

---

From: <[email-masked]>
Date: Wed, 30 May 2007 10:59:42 +0300

> list before Monday June 11.

<not wearing any hats>

Basically repeating the comments I made during the second IETF 
last call:

- I think this document is somewhat useful; and given that there are
others who seem to share this view -- and basically nobody has claimed
that the technical solution is flawed or undesirable -- I think IESG
should publish this document. IMHO not publishing this as a form of
punishment would be a wrong thing to do.

- IMHO the most appropriate status would be Experimental.

- As was already pointed out by others, the IESG should use this
opportunity (before we have deployments) to change the length fields
from 16 bits to 24 bits (the rest of TLS already uses 24-bit length
fields for certificates).

Best regards,
Pasi

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 30 May 2007 21:41:25 +1200

[email-masked] writes:

>I think this document is somewhat useful; and given that there are others who
>seem to share this view -- and basically nobody has claimed that the
>technical solution is flawed or undesirable -- I think IESG should publish
>this document. IMHO not publishing this as a form of punishment would be a
>wrong thing to do.

One potential problem with it is that we're seeing a pile of alternative-
authentication-method proposals for TLS, and there may be better (more
flexible or compatible-with-existing) ways of doing this.  In addition since
there does seem to be a fair bit of interest in this, having a universal
framework to handle it and then allowing individual mechanisms as profiles
within the framework may be a better approach.

At the moment we have two ways to do TLS-alternative-auth, either make it part
of the TLS handshake (that is, modify the crypto portion of the TLS
handshake), or add it as a TLS extension protocol.  The former approach is
used by TLS-KRB5, TLS-PSK, and TLS-SRP.  The latter approach is used by (at
least) TLS-Authz and TLS-EAP (and I think I may have seen one or two probably
now-expired drafts float past in the past as well).

If this is a useful way to handle it, then it looks like the question is
"Which of TLS-Authz, TLS-EAP, (or potential other approaches) provides the
better framework for defining extensible authentication services within TLS?".

Peter.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 30 May 2007 12:06:11 +0200

> better framework for defining extensible authentication services within TLS?".

Hold on!  Tls-authz isn't about authentication.  It is about
authorization.

Authorization is (or at least could be) orthogonal to authentication.  I
haven't seen many competing proposals to solve authorization in TLS,
although the technology is simple if you know about TLS and the
authorization concept.

Btw, one approach to support TLS-alternative-auth is to write profiles
of TLS-PSK for each alternative authentication mechanism.  The mechanism
has to be able to generate cryptographic keys, but I believe good
authentication mechanisms (should) have this property.  Then no changes
to TLS would be required.

/Simon

---

From: Russ Housley <[email-masked]>
Date: Wed, 30 May 2007 18:31:59 -0400

I'm okay with increasing the size as long as others agree with your assessment.

The current version of tls-authz says:

       struct{
          AuthorizationDataEntry authz_data_list<1..2^16-1>;
       } AuthorizationData;

It is easy to change "2^16" to "2^24"

The current version also says:

       opaque X509AttrCert<1..2^16-1>;

       opaque SAMLAssertion<1..2^16-1>;

I have not heard anyone suggest that a single X.509 Attribute 
Certificate or a single SAML Assertion will exceed 64KB, but this 
could be increased as well if there is consensus to do so.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 30 May 2007 18:36:06 -0400

Pasi:

<not wearing any hats either>

>punishment would be a wrong thing to do.

I agree with this position.

>- IMHO the most appropriate status would be Experimental.

I would prefer standards track.

>fields for certificates).

We are discussing this, and if this is the consensus, I'm pleased to 
use a 24-bit length.

Russ

---

From: Sam Hartman <[email-masked]>
Date: Wed, 30 May 2007 19:22:05 -0400

>>>>> "Dean" == Dean Anderson <[email-masked]> writes:

    Dean> I believe the IETF announced that it would be sending this
    Dean> draft back to the 'starting gate'.  To me, that means that
    Dean> TLS has to do several things:

Dean, Eric has corrected your statements about where this draft is in
the process.  However I do want to respond to a couple of your
comments.

    Dean> 1) Consider non-patented alternatives in accordance with
    Dean> RFC2418 and RFC3979.

Dean, this is an excellent idea.
Anyone who wants to including you can discuss alternatives to the technology.
The availability of other ways to do this--particularly when combined with information about whether people are willing to do the necessary work to write up and implement these alternatives--would be great input to the IESG.
I'd appreciate anything you can do in this regard.

As an example, if all the implementers say that they prefer this
solution to alternatives they have considered, and would implement
this solution but not those alternatives, that would be a strong
argument in favor of publication.  If on the other hand people say
that they would write up an alternative and that they would implement
the alternative, that would argue against publication.

What you may be assuming is that we have an obligation to conduct such
a review or that we need to block our work until such a review is
done.  We do have an obligation to consider any alternatives that are
brought forward.  We do have an obligation to solicit comments so
people know they can bring forward alternatives.  But if no one
actually brings forward an alternative we don't have to sit around
waiting.

so if you want to propose an alternative, you should do so.  If you
know others who want to propose an alternative you should encourage
them.

    Dean> 2) Obtain a thorough review and consensus per RFC2026 and
    Dean> RFC2418.

RFC 2418 does not directly apply because this is not a WG document.
However you are completely correct that we need to obtain a consensus.

That's why we are soliciting comments.  The ietf list discussion was
in the minds of some inconclusive.  We're soliciting review here in
hopes that the discussion will lead to a clear consensus.

    Dean> 3) Pass a working group last-call, per RFC2026 and RFC2418.

Not applicable because this is not a WG document.

Thanks for your valuable input.

Sam Hartman
Security Area Director

---

From: Dean Anderson <[email-masked]>
Date: Wed, 30 May 2007 19:25:05 -0400 (EDT)

> License (GUL) protect a *new* method of verifying authorizations.

Please clarify this "GUL". The last proposal you presented on the IETF
list was not a license at all, but instructions on how to request a
license which was to be given for free upon request.  As was noted at
the time, this offer is not a license. As was also noted at the time,
this offer of a free license on request can end at any time.  Your offer
is no different from the free offers on a box of cereal----when the
gizmos run out, the offer is no longer valid, no matter how box tops you
have.  There is nothing that compels RedPhone Security to issue a
license.  There is nothing that prevents RedPhone Security from changing
the terms in the future; after the standard is well entrenched, widely
implemented and used in many products.  There is nothing to compels
successors of RedPhone Security to continue to offer free licenses. 21
years is a long time, in 184 WIPO countries.

If you have changed the terms since last discussed, it would be helpful
to post the new terms.

If you have not changed these terms, then it seems inappropriate to
describe this offer as a licence, since no license is obtained until
__after__ RedPhoneSecurity issues a license in response to a request.  

As I said, 21 years is a long time, and you've already deceived the IETF
at least __7__ times on this issue. I count each time you submitted a
draft that asserted to have no undisclosed patents. There are probably
more times if we count the IESG discussion approving the draft; but
there are at least 7.

> method is reserved by RPS under the GUL.

This is true of any patent, but it is always expensive to litigate.  My
view (as you already know) is that your patent is entirely covered by
prior art, is not novel, and therefore should not be issued by the PTO.  
The PTO issues many such patents, however, despite efforts to identify
prior art and obvious claims.

> infringement against you (except obviously the PAS functions).  

This is FUD.  Obviously, a licensed use can't be objected to as an
infringement;  the use is ___licensed___.  But why the hurry? 

Some background: 

A frequently cited drawback to the patent law of most countries is that
the patent is valid as of the filing date (January 2005 if I recall).  
Unlicensed use of authz-extns between 1/2005 and now is infringement, if
the patent issues.  While RPS __can__ assert a patent infringement claim
for this period, usually halting use is sufficient for most attorney's
to agree not to press the issue.  But there are also criminal penalties
for intentional infringement; these usually only come into play when you
willfully ignore the law and the patent.  You can't bury your head in
the sand and just use authz-extns.  Anyone using authz-extns should stop
immediately or get a license from RPS. But maybe the license isn't a
'good thing'.

Another problem with the GUL is that you must agree to not implement PAS
functions.  Why is this bad? Why the FUD to scare people into licensing
quickly?  Here's why:

Even if you later stop using authz-extns (say because we design a
non-patented alternative), this agreement may still be valid, and it may
be difficult to get out of it---And then you won't be able to implement
PAS functions (well, not without paying RPS or its successors).  So,
executing the agreement may worse even than the patent.  So, it is
probably better to stop using the patented protocol immediately, and pay
cash damages _if_ RPS presses for reparation for the (short) unlicensed
use.

What to do?

It can't be ignored that a patent may issue on the authz-extns draft.  
Implementers who have already implemented authz-extns should remove the
implementation from distribution immediately.  They now have notice of
possible infringement. They should even remove old versions containing
implmentations, and they should notify their users of the likely
infringement and inform their users they should stop using the (likely)  
patented code. You should look closely at the PAS functions and the
license agreement and think about at least the next 21 years, and
possibly forever, before you sign the agreement.

Don't forget to tell the IESG that you don't want this protocol
standardized.

> Since nobody knows precisely which RPS patent claims will issue,
> executing a GUL may help to alleviate concerns right now.  The
> RedPhone Security GUL amounts to a way to guarantee for yourself that
> Sending any "prior art" SAML / AC assertions over TLS will be
> royalty-free.  On the whole it's your choice to use the GUL or not.

Using prior art to create an alternative to authz-extns ensures that no
patents will issue that encumber the standard.  I favor a new draft,
based entirely on prior art.

		--Dean