Skip to main content

Last Call Review of draft-ietf-oauth-pop-architecture-07
review-ietf-oauth-pop-architecture-07-opsdir-lc-morand-2015-12-22-00

Request Review of draft-ietf-oauth-pop-architecture
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-12-15
Requested 2015-12-22
Authors Phil Hunt , Justin Richer , William Mills , Prateek Mishra , Hannes Tschofenig
Draft last updated 2015-12-22
Completed reviews Genart Telechat review of -07 by Matthew A. Miller (diff)
Genart Telechat review of -07 by Matthew A. Miller (diff)
Secdir Telechat review of -06 by Matt Lepinski (diff)
Opsdir Last Call review of -07 by Ron Bonica (diff)
Opsdir Last Call review of -07 by Lionel Morand (diff)
Assignment Reviewer Lionel Morand
State Completed
Review review-ietf-oauth-pop-architecture-07-opsdir-lc-morand-2015-12-22
Reviewed revision 07 (document currently at 08)
Result Has Nits
Completed 2015-12-22
review-ietf-oauth-pop-architecture-07-opsdir-lc-morand-2015-12-22-00
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document is well-written, clear (especially section 6 and 7) and ready to
be published as information RFC. >From the OPS point of view, there is no
specific comment as this document describes only a set of use cases motivating
the need for PoP security mechanism and provides a set of requirements.

However, as an external reviewer, I have some comments, mainly for sake of
clarity in the first part of the document. Up to the authors to take them into
account before publication.

Section 3:

the text put in the introduction of the section 3 describes the primary use
case. It could be put in a specific sub-section (e.g. 3.1), at the same level
than the other scenarios

section 3.1:

the use case is not so clear. It is said that it could be legitimate for a
resource server to re-use a received access token... and that it should be
required to prevent such a re-use. Should it be concluded that both use cases
should be supported by the foreseen solution?

Section 3.2:

What is described in the section is the need for an e2e security, that is also
described in section 3.4. I think that there is no specific reason to have two
separate use cases to motivate the e2e security requirements. They could be
merged into one use case.

Section 3.3:

In the OAuth 2.0 Authorization Framework, the use of TLS is mandatory for
access token exchange. If TLS is not used between the client and the resource
server, we are out of scope of the OAuth 2.0 Authorization Framework, right?
This should be clarified to avoid misinterpretation.

Moreover, it is explicitly said that "In such a case (i.e. no TLS) the bearer
token approach is not possible". Therefore, why is it concluded at the end that
the "the security solution should work in such a scenario"?

Section 5 "Requirements"

I'm assuming that the solution for PoP will have to fulfil "at least" the list
of the requirements defined by RFC4962. It is only an assumption as this not
clearly stated at the beginning of the section whereas the title of the section
is "Requirements". Moreover it seems that some requirements are not part of the
RFC4962. It could be good to highlight them. As it is, we have the impression
that everything was defined by the RFC4962.

Minor comments:

Introduction:

   This document outlines additional use cases requiring stronger
   security protection in Section 3, identifies threats in Section 4,
   proposes different ways to mitigate those threats in Section 6,
   outlines an architecture for a solution that builds on top of the
   existing OAuth 2.0 framework in Section 7, and concludes with a
   requirements list in Section 5.

Either the "requirement list" is not in the right section or the high level
description of the document is wrong as the section 5 cannot come after section
7 :)

Section 3.1:

   In a scenario where a resource server receives a valid access token,
   the resource server then re-uses it with other resource server.

either "with other resource servers" or " with another resource server"

Section 3.2:

   In this use case additional information should be conveyed to the
   resource server to ensure that no entity entity has tampered with the
   TLS/DTLS connection.

s/ that no entity entity/ that no entity

Section 4:

      extend the validity period.  A client, which MAY be a normal
      client or MAY be assumed to be constrained (see [RFC7252]), may
      modify the token to have access to information that they should
      not be able to view.

s/ that they should/ that it should

Best Regards,

Lionel

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration, Orange decline toute
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law; they should not be distributed, used
or copied without authorisation. If you have received this email in error,
please notify the sender and delete this message and its attachments. As emails
may be altered, Orange is not liable for messages that have been modified,
changed or falsified. Thank you.