Re: [OAUTH-WG] Server cret verification in 10.9

Eran Hammer <eran@hueniverse.com> Thu, 08 March 2012 01:18 UTC

Return-Path: <eran@hueniverse.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 39E1C21F85AD for <oauth@ietfa.amsl.com>; Wed, 7 Mar 2012 17:18:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.529
X-Spam-Level:
X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599]
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 T2q3fLIXryUq for <oauth@ietfa.amsl.com>; Wed, 7 Mar 2012 17:18:08 -0800 (PST)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 763CE21E800C for <oauth@ietf.org>; Wed, 7 Mar 2012 17:18:08 -0800 (PST)
Received: (qmail 11759 invoked from network); 7 Mar 2012 23:17:01 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 7 Mar 2012 23:16:57 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 7 Mar 2012 15:57:33 -0700
From: Eran Hammer <eran@hueniverse.com>
To: John Bradley <ve7jtb@ve7jtb.com>, Peter Saint-Andre <stpeter@stpeter.im>
Date: Wed, 07 Mar 2012 15:57:25 -0700
Thread-Topic: [OAUTH-WG] Server cret verification in 10.9
Thread-Index: Acza5vDuN+5YHYebS8uzmfI1xS/n7QhzrIHw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4068@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <90C41DD21FB7C64BB94121FBBC2E723453AAB9653D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4F1E2639.10902@stpeter.im> <494090F8-EEC5-4156-B372-D06745E01552@ve7jtb.com>
In-Reply-To: <494090F8-EEC5-4156-B372-D06745E01552@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Server cret verification in 10.9
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: Thu, 08 Mar 2012 01:18:09 -0000

New text:

          In order to prevent man-in-the-middle attacks, the authorization server MUST implement
          and require TLS with server authentication as defined by <xref target='RFC2818' /> for
          any request sent to the authorization and token endpoints. The client MUST validate the
          authorization server's TLS certificate as defined by <xref target='RFC6125' />, and in
          accordance with its requirements for server identity authentication.

EH

> -----Original Message-----
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> Sent: Tuesday, January 24, 2012 2:24 PM
> To: Peter Saint-Andre
> Cc: Eran Hammer; OAuth WG
> Subject: Re: [OAUTH-WG] Server cret verification in 10.9
> 
> We added the reference to RFC6125 in openID Connect.
> 
> The Client MUST perform a TLS/SSL server certificate check, per
> 	    <xref target="RFC6125">RFC 6125</xref>.
> 
> We wanted to be more general to allow for non http bindings in the future.
> 
> If you don't do it in core, every spec that references core will probably have
> to add it.
> 
> John B.
> 
> 
> On 2012-01-24, at 12:32 AM, Peter Saint-Andre wrote:
> 
> > On 1/20/12 4:46 PM, Eran Hammer wrote:
> >> Stephen asked:
> >>
> >>> (13) 10.9 says that the client MUST verify the server's cert which is
> >>> fine. However, does that need a reference to e.g. rfc 6125? Also, do
> >>> you want to be explicit here about the TLS server cert and thereby
> >>> possibly rule out using DANE with the non PKI options that that WG
> >>> (may) produce?
> >>
> >> Can someone help with this? I don't know enough to address.
> >
> > The OAuth core spec currently says:
> >
> >   The client MUST validate the authorization server's
> >   TLS certificate in accordance with its requirements
> >   for server identity authentication.
> >
> > RFC 2818 has guidance about endpoint identity, in Section 3.1:
> >
> > http://tools.ietf.org/html/rfc2818#section-3.1
> >
> > RFC 6125 attempts to generalize the guidance from RFC 2818 and many
> > similar specs for use by new application protocols. Given that OAuth as
> > defined by the core spec runs over HTTP, I think referencing RFC 2818
> > would make sense. So something like:
> >
> >   The client MUST validate the authorization server's
> >   TLS certificate in accordance with the rules for
> >   server identity authentication provided in Section 3.1
> >   of [RFC2818].
> >
> > Peter
> >
> > --
> > Peter Saint-Andre
> > https://stpeter.im/
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth