IETF Logo Mail Archive

Re: [OAUTH-WG] Security Considerations Section Proposal -02

Oleg Gryb <oleg_gryb@yahoo.com> Thu, 07 April 2011 16:34 UTC

Return-Path: <oleg_gryb@yahoo.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14F7428C161 for <oauth@core3.amsl.com>; Thu, 7 Apr 2011 09:34:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEgL7U04uUUi for <oauth@core3.amsl.com>; Thu, 7 Apr 2011 09:34:54 -0700 (PDT)
Received: from web37603.mail.mud.yahoo.com (web37603.mail.mud.yahoo.com [209.191.87.86]) by core3.amsl.com (Postfix) with SMTP id 0928528C15F for <oauth@ietf.org>; Thu, 7 Apr 2011 09:34:53 -0700 (PDT)
Received: (qmail 30064 invoked by uid 60001); 7 Apr 2011 16:36:34 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1302194194; bh=Fwmic9v2FrXrSYr8aSF7SjMPbCYdUV6cH1kbCQ6RX0s=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=1YPV2OTeJfiBSoGyCDbPDrffHHvtXM1T9wWtTwtFlyvSvddZywBXzePRb12T5PzhNR7jarpLpoQTD9+8tge0tAScPVt3vdxJKMg8lLIzBURvOpEnAbN8flL2NcikCbU14swaqy8uQEmqSmbqi9MrTVnpdqqNW5farZzSeu4I8MQ=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=wej4vvukNUvK8PnoGkAId98qNu7LRKL0M12PndUX/OpIkK11niH13FvUbwvYMhl7OsH3Q1seOAotuuRffks0z0HdlLxc3gQ0PltIDOONdHhT9wcaCRDIuMujjwxexrTbXve9qvqKJjlrogBDTcVMMBtEQBEqb5nFqKsq3eeKLcE=;
Message-ID: <901760.92438.qm@web37603.mail.mud.yahoo.com>
X-YMail-OSG: pDUEh5gVM1nPZ9MT4.SkAMdLLkB3jaOBFLlsDEaaC5zCdyh Lq9UBmPumpHKMqv5_NI8q.KkI.Krzh8IAV3TICfdsRV.K0Re9czSvM0RX2kJ ih2oxSAyaEwZsVfQO05Yw2_H7SIzgSmeMDGrLqT4pwmPayZOq8wp3fZF0WGa qx27Z0dcyAZWLjCHZZ1.qH4sZtSzE6sp0seH62cl.NvgXkTLkuRVkBmV2Kxc BXI3h7SyoZZ5eXlYP4L_LpFzXUxtpDgsYuCVz9Qf9D7EOdi4KUc4EpwtPc4w dy_GTp7TtGYqhL1FGdGBtMqB1O_8ITIkS9BUkzANUqKGWA0pcRZl97gsvd.X rfOBqxO40L9ZOwLZfG9NZhUtLcV9_z_R7oGH2Fe3y444ZGRTF.rAz4pHpZAA R92LUxIa73ylIFg--
Received: from [67.121.115.80] by web37603.mail.mud.yahoo.com via HTTP; Thu, 07 Apr 2011 09:36:34 PDT
X-Mailer: YahooMailRC/559 YahooMailWebService/0.8.109.295617
References: <4D9D6759.3070904@lodderstedt.net>
Date: Thu, 07 Apr 2011 09:36:34 -0700
From: Oleg Gryb <oleg_gryb@yahoo.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>, OAuth WG <oauth@ietf.org>
In-Reply-To: <4D9D6759.3070904@lodderstedt.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [OAUTH-WG] Security Considerations Section Proposal -02
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Oleg Gryb <oleg@gryb.info>
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 07 Apr 2011 16:34:55 -0000

Definitions
"they can seamlessly make use of it capabilities" - its?

2.3 "Application developers MUST NOT store access tokens in non-transient
   memory".
What is non-transient memory? Is non-persistent cookie non-transient? Do we know 
how all browsers store their non-persistent cookies?
What if my non-persistent cookie is swapped to a HD along with my user agent by 
OS?

Consider alternative. Application developers MUST limit the life time and 
accessibility of access tokens in the same way how they protect other secrets on 
their clients. A 'secure' and 'HTTPOnly' attributes MUST be used if an access 
token is stored in a cookie.

2.6.

"MUST NOT be
   transmitted in clear: access tokens"

It contrdicts to the results of our "MUST" vs "SHOULD" discussion. If we have 
SHOULD in the spec, we should use the same here.

2.9.
"It is strongly RECOMMENDED that native application developers use
   external browsers instead of browsers embedded in the application for
   performing the end-user authorization process.  External browsers
   offer a familiar usage experience and a trusted environment, in which
   users can confirm the authentictity of the site"

I'm not sure why we're writing this. Was it proven that embedded browsers are 
less secure than external. Did anyone analyze all mobile proprietary "external"  
and "internal" browsers. Please provide evidence or remove the whole paragraph 
(if such evidence doesn't exist)

2.10.
"The authorization server operators SHOULD require..."
Can this SHOULD be changed to MUST? If it was already discussed, please ignore 
and let me know where.




----- Original Message ----
> From: Torsten Lodderstedt <torsten@lodderstedt.net>
> To: OAuth WG <oauth@ietf.org>
> Sent: Thu, April 7, 2011 12:27:21 AM
> Subject: [OAUTH-WG] Security Considerations Section Proposal -02
> 
> Hi all,
> 
> I just posted a new revision of the proposed text for the core  draft's 
>security considerations section  
>(http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-02).
> 
> The  text makes some strong statements wrt client secrets/authentication, 
>HTTPS,  refresh tokens and other topics. This is to facilitate a clear and  
>understandable specification while also considering (and supporting) _all_  
>relevant use cases (e.g. native apps).
> 
> Since this is the last major  building block of the draft, we would like to 
>include this text as soon as  possible.
> 
> So please give your feedback soon!
> 
> thanks in  advance,
> Torsten.
> _______________________________________________
> OAuth  mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

v2.23.0 | Report a Bug | By Email