Re: [secdir] Secdir review of draft-ietf-oauth-saml2-bearer-21
Brian Campbell <bcampbell@pingidentity.com> Wed, 15 October 2014 13:44 UTC
Return-Path: <bcampbell@pingidentity.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687E31A6FE9 for <secdir@ietfa.amsl.com>; Wed, 15 Oct 2014 06:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.178
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFr1I0QvX3pm for <secdir@ietfa.amsl.com>; Wed, 15 Oct 2014 06:44:18 -0700 (PDT)
Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB5D1A6FD1 for <secdir@ietf.org>; Wed, 15 Oct 2014 06:44:16 -0700 (PDT)
Received: from mail-ig0-f176.google.com ([209.85.213.176]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKVD56MBMPvXBrhDYJec09UWWBL8OVYtC0@postini.com; Wed, 15 Oct 2014 06:44:16 PDT
Received: by mail-ig0-f176.google.com with SMTP id hn15so17357665igb.9 for <secdir@ietf.org>; Wed, 15 Oct 2014 06:44:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.43.76.199 with SMTP id zf7mr2648576icb.57.1413380656147; Wed, 15 Oct 2014 06:44:16 -0700 (PDT)
X-Received: by 10.43.76.199 with SMTP id zf7mr2648551icb.57.1413380655903; Wed, 15 Oct 2014 06:44:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.12.137 with HTTP; Wed, 15 Oct 2014 06:43:45 -0700 (PDT)
In-Reply-To: <CAAX2Qa1WBo=RMXDqbqHJx8pRZqcUYJJDVCJN2-ZxCcKmf_h-uw@mail.gmail.com>
References: <AEBDE45E-963A-47B5-997F-416562FE1B32@inria.fr> <CAAX2Qa1WBo=RMXDqbqHJx8pRZqcUYJJDVCJN2-ZxCcKmf_h-uw@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 15 Oct 2014 07:43:45 -0600
Message-ID: <CA+k3eCRnCd=_Gd3wzt+kN5fSNQn=D_SDBdACWALvhqTS39aSnw@mail.gmail.com>
To: The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-oauth-saml2-bearer@tools.ietf.org, Vincent Roca <vincent.roca@inria.fr>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c3b252ed93960505765399"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/FQgImj92yLjjEkVMJ2ztzPuX4_g
Subject: Re: [secdir] Secdir review of draft-ietf-oauth-saml2-bearer-21
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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 <vincent.roca@inria.fr> > Date: Tue, Oct 14, 2014 at 9:10 AM > Subject: Secdir review of draft-ietf-oauth-saml2-bearer-21 > To: IESG <iesg@ietf.org>, secdir@ietf.org, > draft-ietf-oauth-saml2-bearer@tools.ietf.org > Cc: Vincent Roca <vincent.roca@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.
- [secdir] Secdir review of draft-ietf-oauth-saml2-… Vincent Roca
- Re: [secdir] Secdir review of draft-ietf-oauth-sa… Brian Campbell
- [secdir] Secdir review of draft-ietf-dart-dscp-rt… Tina TSOU
- Re: [secdir] Secdir review of draft-ietf-dart-dsc… Black, David