Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com
 (Postfix) with ESMTP id 1054E1A0584 for <oauth@ietfa.amsl.com>;
 Fri, 25 Apr 2014 09:23:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.146
X-Spam-Level: 
X-Spam-Status: No,
 score=-0.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,
 FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
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 nws0udFPM4jU for
 <oauth@ietfa.amsl.com>; Fri, 25 Apr 2014 09:23:33 -0700 (PDT)
Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com
 [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id 102491A0665 for
 <oauth@ietf.org>; Fri, 25 Apr 2014 09:23:32 -0700 (PDT)
Received: by mail-qc0-f180.google.com with SMTP id w7so4338933qcr.11 for
 <oauth@ietf.org>; Fri, 25 Apr 2014 09:23:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net;
 s=20130820;
 h=x-gm-message-state:content-type:mime-version:subject:from
 :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to;
 bh=ncYy4mCPtYYb7q/diKpls2GQDHIEWRrDww9cLfAkZXs=;
 b=KbFiG5E2v9Lsw3pUWcDlI6RiGpBHmQzc/8NMsiJysPGamxlxTd1BMLe/yz6eAY9USU
 /ZtmbTi/TKOxH2kjOYQxrCXYfLvDsQqhg4ciLQ8vcbbKtVwQh5aQLSz8RUl6kQDPzSyJ
 muvUjIyzmXBPM4l/cAzSQpEgY/jtKD5aUz/9FOeCLq+dmMAkDLPChsgFMmLV8uESjPbS
 BQ/5m8FbMzroqEl2Hyx2mJUs3KGM+wv9vdBqoSzzZV518Gnl2hTmNtPM73JI+PwmIJU6
 j/2JpjTRJht17Ic/l4RgV5tO58jURNYD/OnjDWEIQcZTAY/+vCKYi0qjTohBmmIOODq/ vt0w==
X-Gm-Message-State: ALoCoQn0OT1SxuGFzhs95ilmuzM0etduQ8Vh6O08SHi3r/veharyOLrKG/vPoN+r8N0aqHfTU7nC
X-Received: by 10.140.48.13 with SMTP id n13mr12267554qga.90.1398443006044;
 Fri, 25 Apr 2014 09:23:26 -0700 (PDT)
Received: from [192.168.0.200] ([201.188.68.144]) by mx.google.com with
 ESMTPSA id x2sm15101258qas.26.2014.04.25.09.23.23 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Fri, 25 Apr 2014 09:23:24 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <D225CD69196F3F4A9F4174B2FCA06F8811EC8367@S10BE002.SH10.lan>
Date: Fri, 25 Apr 2014 13:23:23 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <585CA20A-F0D4-441D-81BC-DCA2A049E5F1@ve7jtb.com>
References: <D225CD69196F3F4A9F4174B2FCA06F8811EC7E92@S10BE002.SH10.lan>
 <8CE5B8B4-5CFB-4E1C-B1EC-06D2F0217ED8@adobe.com>
 <D225CD69196F3F4A9F4174B2FCA06F8811EC81D7@S10BE002.SH10.lan>
 <7EF3EC88-B32C-4858-8570-B142A6EEE96C@ve7jtb.com>
 <D225CD69196F3F4A9F4174B2FCA06F8811EC8367@S10BE002.SH10.lan>
To: Andrei Shakirin <ashakirin@talend.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/opyvQStwxRgGhgT-B3g1IQ1gjHU
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Session cookies in OAuth2 flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 25 Apr 2014 16:23:35 -0000

For cross site request forgery you need to validate the value in state =
somehow.   You could store the value in the browser session, or relate =
it somehow to session information in the server.

Making up a random number in the request and checking that there is a =
random number in the response won't help.
Even signing the value of the state is not super useful as the the =
attacker could just separately get a state value from another authn =
request and use that in there cross site request request.

The cookie or hash of some other TLS bound session cookie allows the =
client to detect the XRSF attack without using server side state on the =
client.

John B.


On Apr 25, 2014, at 12:36 PM, Andrei Shakirin <ashakirin@talend.com> =
wrote:

> Hi John,
>=20
> Thanks a lot for your explanation!
>=20
> I am a bit confused regarding "state" parameter and cookies. I thought =
that "state" is included in redirection URI for user-agent and verified =
by client when Authorization server redirects user-agent back.
> It is a way to bind authorization request to response (4.1. =
Authorization Code Grant, steps (A) and (C)).
> Are the cookies really necessary in this case? Can they provide =
additional protection in case if redirect URI manipulated?
>=20
> Regards,
> Andrei.
>=20
>=20
>> -----Original Message-----
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>> Sent: Freitag, 25. April 2014 14:03
>> To: Andrei Shakirin
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Session cookies in OAuth2 flow
>>=20
>> Yes the server can be stateless, though it may need to store client =
credentials
>> and user to validate against, and refresh token grants etc.
>>=20
>> The "state" parameter allows the client to maintain some state =
information
>> across the Oauth authorization request and response.
>>=20
>> Part of the use of that state information by the client allows it to =
protect itself
>> from having authorization requests initiated by 3rd parties that is =
what Sec
>> 10.12 is talking about.
>> In that case the client can save state in a browser cookie or in the =
server and
>> use that to validate the returned state value to assure itself that =
the
>> authorization request came from itself.
>>=20
>> John B.
>>=20
>> On Apr 25, 2014, at 4:08 AM, Andrei Shakirin <ashakirin@talend.com> =
wrote:
>>=20
>>> Hi Antonio,
>>>=20
>>> Thanks for your quick answer.
>>> Important for me is that OAuth2 doesn't force to store client or =
user-agent
>> states in the authorization server, so authorization server can be =
stateless and
>> is not obligated to introduce the sessions at all.
>>>=20
>>> Regards,
>>> Andrei.
>>>=20
>>>> -----Original Message-----
>>>> From: Antonio Sanso [mailto:asanso@adobe.com]
>>>> Sent: Freitag, 25. April 2014 09:02
>>>> To: Andrei Shakirin
>>>> Cc: oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] Session cookies in OAuth2 flow
>>>>=20
>>>> hi Andrei,
>>>>=20
>>>> AFAIU session cookie management is beyond the scope of the OAuth2
>>>> specification.
>>>>=20
>>>> regards
>>>>=20
>>>> antonio
>>>>=20
>>>> On Apr 24, 2014, at 6:39 PM, Andrei Shakirin <ashakirin@talend.com>
>> wrote:
>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> My name is Andrei Shakirin, I am working with OAuth2 =
implementation
>>>>> in
>>>> Apache CXF project.
>>>>> Could you please help me to verify my understanding regarding of
>>>>> using
>>>> session cookies in OAuth2 flow.
>>>>> OAuth2 specification mentions session cookies in:
>>>>> 1) Section 3.1. Authorization Endpoint as possible way to
>>>>> authenticate
>>>> resource owner against authorization server
>>>>> 2) Section 10.12. Cross-Site Request Forgery as possible attack
>>>>> where end-
>>>> user follows a malicious URI to a trusting server including a valid
>>>> session cookie
>>>>>=20
>>>>> My current understanding is:
>>>>> a) using sessions between user-agent and authorization server is
>>>>> optional and
>>>> authorization server is not obligated to keep user state (in case =
if
>>>> user-agent provide authentication information with every request).
>>>>> b) in case if sessions are used (because of any reasons),
>>>>> authorization server
>>>> have to care about additional protection like hidden form fields in
>>>> order to uniquely identify the actual authorization request.
>>>>>=20
>>>>> Is this correct?
>>>>>=20
>>>>> Regards,
>>>>> Andrei.
>>>>>=20
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20