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

Brian Campbell <> Wed, 15 October 2014 13:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 687E31A6FE9 for <>; Wed, 15 Oct 2014 06:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.178
X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jFr1I0QvX3pm for <>; Wed, 15 Oct 2014 06:44:18 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DDB5D1A6FD1 for <>; Wed, 15 Oct 2014 06:44:16 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Wed, 15 Oct 2014 06:44:16 PDT
Received: by with SMTP id hn15so17357665igb.9 for <>; Wed, 15 Oct 2014 06:44:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=N04x3PadiC2NHSw8yOo2Qy9bYpUAVTQBjXXnwPKFzMU=; b=FkzvSRjNUXOudQySDXPfoaBBqBk8KmESx82hHJ/xWpeE1xvwGjZabC/ZdBTwd/Kz+V SVMJEAXm9FtNZ/pM4G8GKNAUE0yD1bKLyGWlmuHVqQi90VWuP0ZBDdKh79OHhGqKr3pR lVSYfgj1gOd3CvwKDdat54XwGRY2zNcabiGhfPS22FOjkYa3vyKmErDDU/9yWd/4m27K aCyctui6cjLLRigIMT1JRkue3SoUCsY6MBjyQcZFpD7kR90E0CMQE8A+Cu4RiEfif/ti vf5ziQJFiCTzu5TmjnXVCKo22aDsYZMoHDSvPWLO8M4jl9bwXt3FvxDz7IaqBeI4erCi 5VfQ==
X-Gm-Message-State: ALoCoQnObdUI5uUdjRU/vHInb3veRBwHZ9J19D2wnGAvhvl9qC/J1pD3DLgFrvYMomj3AkjNnCyluPqz9jZr14s0tr3koyHMQEceUpvIQBmZcxtgfg60KAe0mTLz0gFOe5UHbt1jVAGaNq4QckhRXqNrCvmaLk3+Og==
X-Received: by with SMTP id zf7mr2648576icb.57.1413380656147; Wed, 15 Oct 2014 06:44:16 -0700 (PDT)
X-Received: by with SMTP id zf7mr2648551icb.57.1413380655903; Wed, 15 Oct 2014 06:44:15 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 15 Oct 2014 06:43:45 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Brian Campbell <>
Date: Wed, 15 Oct 2014 07:43:45 -0600
Message-ID: <>
To: The IESG <>, "" <>,, Vincent Roca <>, oauth <>
Content-Type: multipart/alternative; boundary="001a11c3b252ed93960505765399"
Subject: Re: [secdir] Secdir review of draft-ietf-oauth-saml2-bearer-21
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Oct 2014 13:44:24 -0000

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 <>
> Date: Tue, Oct 14, 2014 at 9:10 AM
> Subject: Secdir review of draft-ietf-oauth-saml2-bearer-21
> To: IESG <>,,
> Cc: Vincent Roca <>
> 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,
> 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 ( )
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.

Perhaps you can help me with the tool usage here?

In the source XML I've got <?rfc include=''
?> in the references and
has that URL via <format type="PDF" target=""/>
but the URL doesn't show up in the rendered document.

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