Re: [TLS] Review of draft-housley-tls-authz-extns-05

Russ Housley <> Wed, 31 May 2006 22:02 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FlYlU-0007xG-Vs; Wed, 31 May 2006 18:02:08 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1FlYlT-0007x8-7P for; Wed, 31 May 2006 18:02:07 -0400
Received: from ([]) by with smtp (Exim 4.43) id 1FlYlQ-0006dd-W4 for; Wed, 31 May 2006 18:02:07 -0400
Received: (qmail 11190 invoked by uid 0); 31 May 2006 22:01:57 -0000
Received: from unknown (HELO ( by with SMTP; 31 May 2006 22:01:57 -0000
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Wed, 31 May 2006 18:02:02 -0400
To: <>
From: Russ Housley <>
Subject: Re: [TLS] Review of draft-housley-tls-authz-extns-05
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F2402AE176A@esebe105.NOE.Noki>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>


>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.

Does this proposed text solve your concern?

    The use of bearer SAML assertions allows an eavesdropper or a
    man-in-the-middle to capture the SAML assertion and try to reuse
    it in another context.  The constraints discussed in Section 3.3.2
    might be effective against an eavesdropper, but they are less likely
    to be effective against a man-in-the-middle.  Authentication of both
    parties in the TLS session, which involves the use of client
    authentication, will prevent an undetected man-in the-middle, and
    the use of the double handshake illustrated in Figure 2 will prevent
    the disclosure of the bearer SAML assertion to any party other than
    the TLS peer.

>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...

Does this proposed text solve your concern?

    When SAMLAssertion is used, the field contains an XML-encoded
    <Assertion> element using the AssertionType complex type as
    defined in [SAML1.1][SAML2.0].

>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).

Draft -06 was posted to remove all references to KeyNote.

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

This was fixed in draft -06 too.


TLS mailing list