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

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