Last Call Review of draft-ietf-httpbis-p7-auth-24
review-ietf-httpbis-p7-auth-24-secdir-lc-kent-2013-10-31-00

I reviewed
        this document
        as part of the security directorate's ongoing effort to review
        all IETF
        documents being processed by the IESG.

 
        

These comments were written primarily for the benefit of
        the security
        area directors.

  

Document
        editors, WG
        chairs and ADs should treat these comments just like any other
        last call comments.




 




The document
        obsoletes RFC
        2616 and updates 2617. It says that it “defines HTTP/1.1 access
        control and
        authentication.” I have not been tracking httpbis closely enough
        to know the
        specific motivations for generating this doc, so my review is
        unbiased by that context. 




 




I see that
        “ought” is used
        in two places on page 6, but not in uppercase as per RFC 6919.
        The authors
        should revisit the use of this term here. 




 




Also on page
        6 it appears
        that the phrase “receipt of” was omitted in two places:




 




      

Upon
      

<>
        

a
      request for a protected resource that omits credentials




 




      

Likewise,
upon
      

<>


      a request that requires authentication by proxies 




 




Later on page
        6 the text
        says:




 




   

The
      HTTP
      protocol does not restrict applications to this simple




  
      

challenge-response framework for access authentication.

  

Additional




   

mechanisms
      MAY
      be used, such as 

encryption 

at
      the transport
      level or




   

via
      message
      encapsulation, and with additional header fields




   

specifying
authentication
      information.

  

However,
      such additional




   

mechanisms
      are
      not defined by this specification.




 




Encryption is
        not, per se,
        an authentication mechanism. Please revise this text.




 




In Section
        2.2 the text
        says:




 




   

The
      protection
      space determines the domain over which credentials can




   

be
      automatically
      applied.

  

If a prior
      request has been
      authorized,




   

the
      user agent
      MAY reuse the same credentials for all other requests




   

within
      that
      protection space for a period of time determined by the




   

authentication
scheme,
      parameters, 

and/or user preference

.

  




 




 




I’m not clear
        how user
        preferences fit into this process. It would seem that the server
        would decide
        whether a prior authorization is valid for later requests, not a
        user.




 




The end of
        Section 2.2
        includes the word “might” but not uppercase, as per RFC 6919. I
        again suggest
        that the authors reconsider using this term in this context.




 




In Section
        4.3, the text says:




 




    

A
      proxy MAY
      relay




   

the
      credentials
      from the client request to the next proxy if that is




   

the
      mechanism by
      which the proxies cooperatively authenticate a given




   

request.




 




If, as stated
        here, a set
        of proxies cooperatively authenticate a request, then isn’t this
        a MUST vs. a
        MAY?




 




In Section
        4.4 the text
        says:




 




      

Note:
      The
      challenge grammar production uses the list syntax as




      

well.

  

Therefore, a sequence of
      comma, whitespace,
      and comma can




      

be
      considered
      

both

 as applying to the preceding
      challenge, or
      to




      

be
      an empty
      entry in the list of challenges.

  

In
practice,
      this




      

ambiguity
does
      not affect the semantics of the header field value




 




Should “both”
        be “either”
        in the above text? Does the potentially ambiguous construct ever
        take on both
        meanings simultaneously?




 




Section 5.1.2
        uses “ought”
        when discussing definitions for new authentication schemes. See
        comments above
        re use of this term.

 The same section also uses
        the phrase “need to” twice, where MUST seems appropriate.







 




The Security
        Considerations section (6) is about one page in length. It
        references the SC
        sections in two in I-Ds: draft-ietf-httpbis-p1-messaging-24 and
        draft-ietf-httpbis-p2-semantics-24.

 

Both
        of these I-Ds have non-trivial SC sections, but one cannot say
        that this
        document has an acceptable SC section until those documents are
        finalized. They are both normative references, so this doc will
        nor progress independently, but there will still be a need to
        revisit this SC when those SCs are finalized.




 




The SC
        section here
        addresses only two issues: purging credentials in clients and
        user agents, and
        protection spaces. The discussion of the former topic does not
        discuss how
        credential purging applies to proxies. Also, it is not clear
        that a user
        control for credential purging will have the desired effect
        given a potentially
        complex GUI environment. The discussion of protection spaces
        provides useful
        suggestions on how to minimize credential exposure. 




 




I was a bit
        surprised that
        there was no advice deprecating the use of passwords as
        credentials, if only to
        make a statement on this topic.