Subject: Review of draft-housley-tls-authz-extns-05

From: <[email-masked]>
Date: Tue, 23 May 2006 11:00:52 +0300

The part about X.509 attribute certificates looks fine, but
at least the SAML part still needs some work:

1) I think the document needs to discuss the security considerations
   of bearer SAML assertions in more detail. While the countermeasures
   described in 3.3.2 may help against passive eavesdroppers, they 
   still allow an active MiTM to "steal" the permission. This is IMHO 
   a significant difference to typical SAML usage with HTTP-over-TLS,
   where the server is authenticated before the bearer assertion is
   sent.

2) Section 3.3.2: "When SAMLAssertion is used, the field contains XML 
   constructs with a nested structure defined in [SAML1.1][SAML2.0]."
   This needs to be much more specific than "some XML from these 
   documents". What element/elements? Is this an XML document
   (with XML declaration etc.), or just a "fragment"? Which encoding? 
   And so on...

3) The document is last called for Proposed Standard, but contains
   a normative reference to Informational RFC (RFC 2704). I'd 
   suggest removing the KeyNote stuff from this document (if someone
   really wants to do KeyNote, it can be a separate document).

Minor editorial comments:

4) Section 2.3: the list type is "AuthorizationDataFormats" but
   enum is spelled "AuthzDataFormat".

Best regards,
Pasi

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

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 May 2006 12:58:30 -0400

Pasi:

>    really wants to do KeyNote, it can be a separate document).

I would like to propose a way forward on this point.  It involves 
three changes.

First, I suggest a different code point assignment:

       enum {
          x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
          saml_assertion_url(3), keynote_assertion_list(64), (255)
       } AuthzDataFormat;

Second, I propose the following text:

    3.3.4. KeyNote Assertion List (Informative)

    When KeyNoteAssertion List is used, the field contains an ASCII-
    encoded list of signed KeyNote assertions, as described in RFC 2704
    [KEYNOTE].  The assertions are separated by two '\n' (newline)
    characters.  A KeyNote assertion is a structure similar to a public
    key certificate; the main difference is that instead of a binding
    between a name and a public key, KeyNote assertions bind public keys
    to authorization rules that are evaluated by the peer when the sender
    later issues specific requests.

    When making an authorization decision based on a list of KeyNote
    assertions, proper linkage between the KeyNote assertions and the
    public key certificate that is transferred in the TLS Certificate
    message is needed.  Receivers of a KeyNote assertion list should
    initialize the ACTION_AUTHORIZER variable to be the sender's public
    key, which was used to authenticate the TLS exchange.

Third, I suggest making the [KEYNOTE] reference informational.

What do you think?  Is this a reasonable compromise?

Russ

---

From: <[email-masked]>
Date: Wed, 24 May 2006 11:11:49 +0300

Russ,

I don't think this is good use of "informative" text. Other
standards bodies often mark some sections of a specification 
as informative, but those sections are text that is helpful 
for understanding the specification, but is not required to 
implement it.

The KeyNote section is clearly part of the technical specification,
and required reading to get interoperable implementations of this
feature.

Also, my reading of RFC2026 is that the "Proposed Standard" status
applies to whole documents, and I found nothing there that would
support approving only some specific sections of a document as 
Proposed Standard, while leaving other sections as Informational
or Experimental....

Best regards,
Pasi

> -----Original Message-----
> From: ext Russ Housley [mailto:[email-masked]] 
> Sent: 23 May, 2006 19:59
> To: Eronen Pasi (Nokia-NRC/Helsinki)
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [TLS] Review of draft-housley-tls-authz-extns-05
> 
> Pasi:
>

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 May 2006 11:07:59 -0400

Russ,

I concur with Pasi's observations.  I don't recall seeing a similar 
structure in an RFC, where a part is informative, in what is 
otherwise a standards track document.

Steve

---

From: Russ Housley <[email-masked]>
Date: Wed, 24 May 2006 14:57:21 -0400

Right.  I am proposing the addition of "(Informative)" after the 
KeyNote section title.  Also, I proposed assigning the KeyNote code 
point from the "specification required" set of numbers instead of the 
set that is associated with standards track documents.

Russ

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 24 May 2006 18:42:20 -0400

On Wednesday, May 24, 2006 02:57:21 PM -0400 Russ Housley 
<[email-masked]> wrote:

> Right.  I am proposing the addition of "(Informative)" after the KeyNote
> section title.  Also, I proposed assigning the KeyNote code point from
> the "specification required" set of numbers instead of the set that is
> associated with standards track documents.

Then I think you should do it in a separate document.

Labelling a section as "informative" does not make it true.  The proposed 
text describes how to implement a feature, and as Pasi points out, it is 
impossible to produce interoperable implementations of that feature without 
reading that section.  Thus, the section is not informative in nature; it 
is a normative description of an optional feature.  The same applies to the 
reference.

What you really want to do is be able to declare that part of the document 
to be informational.  Thus there would be no downreference, and a year or 
ten from now when you want to advance the document to draft, it won't be 
held back due to the lack of independent interoperable implementations of 
the optional feature.  Of course, then you'd end up with the number 
allocation being a normative downreference from the standards-track portion 
of the document to the informational portion, but that can be resolved 
easily enough, since it's really just prepopulating a registry.

Unfortunately, our process doesn't have any mechanism for documents which 
have both a standards-track part and an informational part.  While I think 
what you're trying to do here is reasonable in its intent, I also think 
that it's likely to create trouble down the road, not because of the 
normative downref to RFC2704, but because of confusion about the status of 
the non-standards-track portion of the document.  Not to mention the 
precedent it sets for the next time when someone wants to do the same sort 
of thing, but with bad intent and undesirable results.

-- Jeff

---

From: "Fleischman, Eric" <[email-masked]>
Date: Wed, 24 May 2006 16:10:45 -0700

I am told during the last IETF's Social Event, Dave Clark made a
presentation that again observed that all of the ARPAnet's historicly
unsolved networking problems persist in the Internet today. I wasn't
there, but I am seeking a paper that I could reference that makes that
very point. Did Dave point to a paper during his speech? If not, can
anybody point me to a published paper dealing with this topic?

Thanks.

--Eric