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

From: <[email-masked]>
Date: Sat, 3 Jun 2006 19:18:40 +0300

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Sam Hartman <[email-masked]>
Date: Sat, 03 Jun 2006 13:44:56 -0400

>>>>> "p" ==   <[email-masked]> writes:

    >> defined in [SAML1.1][SAML2.0].

    p> We also need to specify the character-to-octet encoding (UTF-8
    p> would be the most logical alternative).

It's my understanding that saying it is XML already gives us that:
mandatory UTF8 or UTF16 support at the encoder's option.

---

From: Russ Housley <[email-masked]>
Date: Sat, 03 Jun 2006 14:36:13 -0400

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

Russ

---

From: Sam Hartman <[email-masked]>
Date: Sat, 03 Jun 2006 14:47:50 -0400

>>>>> "Russ" == Russ Housley <[email-masked]> writes:

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

Russ, please confirm with an XML expert that restricting to UTF8 is
acceptable.  In the past Scott would object to that.  My preference is
for you to say nothing about character encoding unless you need to do
so to be unambiguous.

---

From: Russ Housley <[email-masked]>
Date: Sat, 03 Jun 2006 17:48:41 -0400

The text that I proposed said noting.  Here is my proposed way 
forward:  Post the test that I proposed, then ask Scott to look at 
it.  If he recommends a character set statement, we'll add it during 
IESG Evaluation, probably with an RFC Editor note.

Russ

---

From: <[email-masked]>
Date: Mon, 5 Jun 2006 12:00:06 +0300

> mandatory UTF8 or UTF16 support at the encoder's option.

Yes, but the recipient has to know which encoding was used (others 
than UTF8/UTF16 are permitted). 

In a complete XML document, the XML declaration usually contains 
this information (e.g. "<?xml encoding='UTF-8'?>">, but currently
the AuthorizationData contains just one Assertion element, not
a complete document.

I'm not really an XML expert, but I think the options available
to use would be including this information in the "transport"
(e.g., specify it's UTF-8, or include a field for encoding name),
or mandating that AuthorizationData has to include the XML text
declaration before the Assertion element.

Any opinions from XML experts?

Best regards,
Pasi