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

Please hold off on editorial feedback. Trying to figure out section numbers after the move is just too annoying.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Oleg Gryb
> Sent: Thursday, April 07, 2011 9:37 AM
> To: Torsten Lodderstedt; OAuth WG
> Subject: Re: [OAUTH-WG] Security Considerations Section Proposal -02
> 
> 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
> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth