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

Russ Housley <housley@vigilsec.com> Sat, 03 June 2006 18:36 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmaz3-0003SF-4T; Sat, 03 Jun 2006 14:36:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fmaz1-0003SA-IF for tls@ietf.org; Sat, 03 Jun 2006 14:36:23 -0400
Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fmaz0-0006Nc-B6 for tls@ietf.org; Sat, 03 Jun 2006 14:36:23 -0400
Received: (qmail 6309 invoked by uid 0); 3 Jun 2006 18:36:17 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.46) by woodstock.binhost.com with SMTP; 3 Jun 2006 18:36:17 -0000
Message-Id: <7.0.0.16.2.20060603143541.0700f438@vigilsec.com>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16
Date: Sat, 03 Jun 2006 14:36:13 -0400
To: <Pasi.Eronen@nokia.com>
From: Russ Housley <housley@vigilsec.com>
Subject: RE: [TLS] Review of draft-housley-tls-authz-extns-05
In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F2402BBFCC6@esebe105.NOE.Noki a.com>
References: <7.0.0.16.2.20060531173828.07a36e28@vigilsec.com> <B356D8F434D20B40A8CEDAEC305A1F2402BBFCC6@esebe105.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: hartmans-ietf@mit.edu, mark@redphonesecurity.com, tls@ietf.org
X-BeenThere: tls@lists.ietf.org
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." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

Great.  I'll make these updates and submit the revised document.

Russ

At 12:18 PM 6/3/2006, Pasi.Eronen@nokia.com wrote:
>Russ Housley wrote:
>
> > >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.
>
>Yes, this is significantly better.
>
> > >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].
>
>We also need to specify the character-to-octet encoding (UTF-8 would
>be the most logical alternative).
>
>Best regards,
>Pasi


_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls