Re: [OAUTH-WG] Secdir review of draft-ietf-oauth-saml2-bearer-21

[Brian Campbell <[e-mail]>]

Thanks for your review and feedback, Vincent.  I'm adding the working group
to the thread so they’re aware of the comments. Replies are inline below...


From: Vincent Roca <[e-mail]>
> Date: Tue, Oct 14, 2014 at 9:10 AM
> Subject: Secdir review of draft-ietf-oauth-saml2-bearer-21
> To: IESG <[e-mail]>, [e-mail],
> [e-mail]
> Cc: Vincent Roca <[e-mail]>
>
>
> Hello,
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors. Document editors and WG chairs should treat
> these comments just like any other last call comments.
>
> IMHO, the document is *almost ready*. I just have minor comments:
>
> SAML and OAUTH are already covered by extensive, detailed security and
> privacy
> considerations sections.
>
> I agree with the authors there is no need to duplicate text in the present
> document.
> However I have two comments:
>
> 1- it is mentioned that replay attack protection is not mandatory, but
> there is no
> justification. On the opposite, protection against replay attacks is
> mentioned at
> several places in [OASIS.saml-sec-consider-2.0-os] (e.g., 6.1.2, 6.4.5,
> 6.5.2, 6.5.6,
> 7.1.1.4). I don’t know to what extent the situation differs, but I’m
> curious to know
> why it is so.
>


In the SAML 2.0 Profile for OAuth 2.0 Client Authentication and
Authorization Grants the client is not passive (like a web browser in the
case of many SAML profiles/bindings) but rather an active client which
either creates the assertion itself or obtains it from a trusted 3rd party
system like a security token service. In that sense, it's most analogous to
6.1.2 of OASIS.saml-sec-consider-2.0-os which discusses replay in the
context of the SOAP binding and says there "is little vulnerability to
replay attacks" and that "the best way to prevent replay attacks is to
prevent the message capture in the first place" going on to say that TLS
does this for point to point communication.

The general Assertion Framework for OAuth 2.0 Client Authentication and
Authorization Grants, which the SAML document is a concrete profile of,
discusses replay some in section 8.2 (
https://tools.ietf.org/html/draft-ietf-oauth-assertions-17#section-8.2 )
and says similar things.

In my own personal view, I think tracking assertion ids and rejecting those
that have been seen before does more harm to interoperability and
deployment at scale than good in mitigating a threat that's already
reasonably mitigated by other means. Others have wanted to have the option
in the documents, however, which is (as I recall) where the optionality of
it comes from.




>
> 2- [OASIS.saml-sec-consider-2.0-os] reference does not include any URL.
> It’s probably
> worth to add it.
> http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf
>
>

Perhaps you can help me with the tool usage here?

In the source XML I've got <?rfc include='
http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-sec-consider-2.0-os.xml'
?> in the references and
http://xml.resource.org/public/rfc/bibxml2/reference.OASIS.saml-sec-consider-2.0-os.xml
has that URL via <format type="PDF" target="
http://docs.oasis-open.org/security/saml/v2.0/saml-sec-consider-2.0-os.pdf"/>
but the URL doesn't show up in the rendered document.

The situation is the same for all the SAML references, FWIW.