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 <vincent.r...@inria.fr> > Date: Tue, Oct 14, 2014 at 9:10 AM > Subject: Secdir review of draft-ietf-oauth-saml2-bearer-21 > To: IESG <i...@ietf.org>, sec...@ietf.org, > draft-ietf-oauth-saml2-bea...@tools.ietf.org > Cc: Vincent Roca <vincent.r...@inria.fr> > > > 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.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
