[OAUTH-WG] Security Considerations (was draft-ietf-oauth-saml2-bearer-17)

Brian Campbell <bcampbell@pingidentity.com> Mon, 04 November 2013 21:20 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A58311E822B for <oauth@ietfa.amsl.com>; Mon, 4 Nov 2013 13:20:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.938
X-Spam-Level:
X-Spam-Status: No, score=-5.938 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CX36FPYWIYMM for <oauth@ietfa.amsl.com>; Mon, 4 Nov 2013 13:20:23 -0800 (PST)
Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id B50F411E8163 for <oauth@ietf.org>; Mon, 4 Nov 2013 13:19:54 -0800 (PST)
Received: from mail-ie0-f172.google.com ([209.85.223.172]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKUngPetMWbRtSt/uS0TqVPXscuaQk8Jq/@postini.com; Mon, 04 Nov 2013 13:19:54 PST
Received: by mail-ie0-f172.google.com with SMTP id tp5so13705696ieb.17 for <oauth@ietf.org>; Mon, 04 Nov 2013 13:19:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=V1uC18y/HHzrWFDECYdkRqNsR15GS2jc7AtmGyZsuZo=; b=AEIKRJvlEjoxagOlwLvGe8CmVwigjhIkP6S8yWy6YS0j9MD92sDy9gP9tcfRTZ7bU4 UnHnvN9afZ79vbNLMJp5zdy75UKvtUdmlHm9Cz+R0+woQEivMYFQ/ThVuC/y48d09F7C tjM7AkPXmgV5iTGKIQxklHypcOlf3Syha6b4QXwWucJCIM1O+3knterNG1yxMaOiktr9 wwu6qkYEXzmxt4m9hwVTW6AS9WCNGB4ILfDjk6P/GTzX6KeR+DkwsTi66kxj2yS/duaK 5JR2VYAMRlPDa8pv1uQcDLMRszIUNeex4WV/zT9QHo3myjrQ8YtZlicDMNqGfqqEdX7y FW8Q==
X-Gm-Message-State: ALoCoQntYcPSQEP+jOYDPGbcMfImDPKalAOSbT/unKR7RyQ9XHUWzGlmNX8h4zonZsX3e3JdBuwfL0I1IrL0rZZ8HZKSQOlG3RlhGuV9mXc5AgeLAFW2M49wUtTad8NzXJuCJQCuA3kiiflYAQ3/xfG92J3nltymCQ==
X-Received: by 10.50.126.74 with SMTP id mw10mr13741125igb.24.1383599994263; Mon, 04 Nov 2013 13:19:54 -0800 (PST)
X-Received: by 10.50.126.74 with SMTP id mw10mr13741119igb.24.1383599994182; Mon, 04 Nov 2013 13:19:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.245.233 with HTTP; Mon, 4 Nov 2013 13:19:23 -0800 (PST)
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 04 Nov 2013 13:19:23 -0800
Message-ID: <CA+k3eCQtssZtfCCaroAgM31jQX8bW6F7_-CAaxKj=MCL=U11YQ@mail.gmail.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: [OAUTH-WG] Security Considerations (was draft-ietf-oauth-saml2-bearer-17)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2013 21:20:34 -0000

On Sat, Nov 2, 2013 at 2:07 AM, Hannes Tschofenig
<hannes.tschofenig@gmx.net> wrote:
> Security Consideration section:
>
>
> I believe the section needs to say two things into addition to the reference
> to the other specifications, which are already included in the security
> consideration section:
>
> a) The specification does not mandate replay protection for the SAML
> assertion usage for neither the authorization grant nor for the client
> authentication. It is an optional feature.

Okay, I'll add some text about that. I think a word or two about it
should go into Interoperability Considerations as well.

> b) There is actually no authentication happening when these SAML assertions
> are used for client authentication and for the authorization grant (in the
> classical definition of authentication). This may be surprising to some why
> typically assume that the client would have to demonstrate proof of
> possession of a secret, which isn't the case here.

I'm not sure I fully understand what you mean. Maybe it's some
semantics around "authentication." Can you explain more or propose
some text?

> It would have been possible to provide more enhanced funtionality (and SAML
> supports this as well) but it is not provided in the specification. Maybe a
> future specification will provide that functionalility. I think it is worth pointing out.

Can you give some examples or propose some text?