
INTRODUCTION, paragraph 1:
OLD:

 HTTPbis Working Group                                   R. Fielding, Ed.
 Internet-Draft                                                     Adobe
 Obsoletes: 2616 (if approved)                            J. Reschke, Ed.
 Updates: 2617 (if approved)                                   greenbytes
 Intended status: Standards Track                            June 6, 2014
 Expires: December 8, 2014

NEW:

 Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
 Request for Comments: 7235                                         Adobe
 Obsoletes: 2616                                          J. Reschke, Ed.
 Updates: 2617                                                 greenbytes
 Category: Standards Track                                      June 2014
 ISSN: 2070-1721


INTRODUCTION, paragraph 2:
OLD:

          Hypertext Transfer Protocol (HTTP/1.1): Authentication
                    draft-ietf-httpbis-p7-auth-latest

NEW:

          Hypertext Transfer Protocol (HTTP/1.1): Authentication


INTRODUCTION, paragraph 5:
OLD:

 Editorial Note (To be removed by RFC Editor)
 
    Discussion of this draft takes place on the HTTPBIS working group
    mailing list (ietf-http-wg@w3.org), which is archived at
    <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
 
    The current issues list is at
    <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
    documents (including fancy diffs) can be found at
    <http://tools.ietf.org/wg/httpbis/>.
 
    _This is a temporary document for the purpose of tracking the
    editorial changes made during the AUTH48 (RFC publication) phase._
 
 Status of This Memo

NEW:

 Status of This Memo


INTRODUCTION, paragraph 6:
OLD:

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.

NEW:

    This is an Internet Standards Track document.


INTRODUCTION, paragraph 7:
OLD:

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

NEW:

    This document is a product of the Internet Engineering Task Force
    (IETF).  It represents the consensus of the IETF community.  It has
    received public review and has been approved for publication by the
    Internet Engineering Steering Group (IESG).  Further information on
    Internet Standards is available in Section 2 of RFC 5741.


INTRODUCTION, paragraph 8:
OLD:

    This Internet-Draft will expire on December 8, 2014.

NEW:

    Information about the current status of this document, any errata,
    and how to provide feedback on it may be obtained at
    http://www.rfc-editor.org/info/rfc7235.


INTRODUCTION, paragraph 14:
OLD:

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
      1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  4
      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  4
    2.  Access Authentication Framework  . . . . . . . . . . . . . . .  4
      2.1.  Challenge and Response . . . . . . . . . . . . . . . . . .  4
      2.2.  Protection Space (Realm) . . . . . . . . . . . . . . . . .  6
    3.  Status Code Definitions  . . . . . . . . . . . . . . . . . . .  7
      3.1.  401 Unauthorized . . . . . . . . . . . . . . . . . . . . .  7
      3.2.  407 Proxy Authentication Required  . . . . . . . . . . . .  7
    4.  Header Field Definitions . . . . . . . . . . . . . . . . . . .  8
      4.1.  WWW-Authenticate . . . . . . . . . . . . . . . . . . . . .  8
      4.2.  Authorization  . . . . . . . . . . . . . . . . . . . . . .  9
      4.3.  Proxy-Authenticate . . . . . . . . . . . . . . . . . . . .  9
      4.4.  Proxy-Authorization  . . . . . . . . . . . . . . . . . . . 10
    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
      5.1.  Authentication Scheme Registry . . . . . . . . . . . . . . 10
        5.1.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 10
        5.1.2.  Considerations for New Authentication Schemes  . . . . 10
      5.2.  Status Code Registration . . . . . . . . . . . . . . . . . 12
      5.3.  Header Field Registration  . . . . . . . . . . . . . . . . 12
    6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
      6.1.  Confidentiality of Credentials . . . . . . . . . . . . . . 13
      6.2.  Authentication Credentials and Idle Clients  . . . . . . . 13
      6.3.  Protection Spaces  . . . . . . . . . . . . . . . . . . . . 14
    7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
      8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
      8.2.  Informative References . . . . . . . . . . . . . . . . . . 15
    Appendix A.  Changes from RFCs 2616 and 2617 . . . . . . . . . . . 16
    Appendix B.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 16
    Appendix C.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 16
    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

NEW:

    1. Introduction ....................................................3
       1.1. Conformance and Error Handling .............................3
       1.2. Syntax Notation ............................................3
    2. Access Authentication Framework .................................3
       2.1. Challenge and Response .....................................3
       2.2. Protection Space (Realm) ...................................5
    3. Status Code Definitions .........................................6
       3.1. 401 Unauthorized ...........................................6
       3.2. 407 Proxy Authentication Required ..........................6
    4. Header Field Definitions ........................................7
       4.1. WWW-Authenticate ...........................................7
       4.2. Authorization ..............................................8
       4.3. Proxy-Authenticate .........................................8
       4.4. Proxy-Authorization ........................................9
    5. IANA Considerations .............................................9
       5.1. Authentication Scheme Registry .............................9
            5.1.1. Procedure ...........................................9
            5.1.2. Considerations for New Authentication Schemes ......10
       5.2. Status Code Registration ..................................11
       5.3. Header Field Registration .................................11
    6. Security Considerations ........................................12
       6.1. Confidentiality of Credentials ............................12
       6.2. Authentication Credentials and Idle Clients ...............12
       6.3. Protection Spaces .........................................13
    7. Acknowledgments ................................................14
    8. References .....................................................14
       8.1. Normative References ......................................14
       8.2. Informative References ....................................14
    Appendix A. Changes from RFCs 2616 and 2617 .......................16
    Appendix B. Imported ABNF .........................................16
    Appendix C. Collected ABNF ........................................17
    Index .............................................................18


Section 2.1., paragraph 7:
OLD:

    A 401 (Unauthorized) response message is used by an origin server to
    challenge the authorization of a user agent, including a WWW-
    Authenticate header field containing at least one challenge
    applicable to the requested resource.

NEW:

    A 401 (Unauthorized) response message is used by an origin server to
    challenge the authorization of a user agent, including a
    WWW-Authenticate header field containing at least one challenge
    applicable to the requested resource.


Section 2.1., paragraph 8:
OLD:

    A 407 (Proxy Authentication Required) response message is used by a
    proxy to challenge the authorization of a client, including a Proxy-
    Authenticate header field containing at least one challenge
    applicable to the proxy for the requested resource.

NEW:

    A 407 (Proxy Authentication Required) response message is used by a
    proxy to challenge the authorization of a client, including a
    Proxy-Authenticate header field containing at least one challenge
    applicable to the proxy for the requested resource.


Section 5.5, paragraph 2:
OLD:

    For historical reasons, a sender MUST only generate the quoted-string
    syntax.  Recipients might have to support both token and quoted-
    string syntax for maximum interoperability with existing clients that
    have been accepting both notations for a long time.

NEW:

    For historical reasons, a sender MUST only generate the quoted-string
    syntax.  Recipients might have to support both token and
    quoted-string syntax for maximum interoperability with existing
    clients that have been accepting both notations for a long time.


Section 4.1., paragraph 3:
OLD:

    A server generating a 401 (Unauthorized) response MUST send a WWW-
    Authenticate header field containing at least one challenge.  A
    server MAY generate a WWW-Authenticate header field in other response
    messages to indicate that supplying credentials (or different
    credentials) might affect the response.

NEW:

    A server generating a 401 (Unauthorized) response MUST send a
    WWW-Authenticate header field containing at least one challenge.  A
    server MAY generate a WWW-Authenticate header field in other response
    messages to indicate that supplying credentials (or different
    credentials) might affect the response.


Section 5.1.2., paragraph 4:
OLD:

    o  The "token68" notation was introduced for compatibility with
       existing authentication schemes and can only be used once per
       challenge or credential.  Thus, new schemes ought to use the auth-
       param syntax instead, because otherwise future extensions will be
       impossible.

NEW:

    o  The "token68" notation was introduced for compatibility with
       existing authentication schemes and can only be used once per
       challenge or credential.  Thus, new schemes ought to use the
       auth-param syntax instead, because otherwise future extensions
       will be impossible.


Section 6., paragraph 1:
OLD:

    This section is meant to inform developers, information providers,
    and users of known security concerns specific to HTTP authentication.
 
    More general security considerations are addressed in HTTP messaging
    [RFC7230] and semantics [RFC7231].

NEW:

    This section is meant to inform developers, information providers,
    and users of known security concerns specific to HTTP authentication.
    More general security considerations are addressed in HTTP messaging
    [RFC7230] and semantics [RFC7231].


Section 8.1., paragraph 0:
OLD:

 8.  References
 8.1.  Normative References

NEW:

 8.  References
 
 8.1.  Normative References


Section 8.1., paragraph 3:
OLD:

    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Message Syntax and Routing",
               draft-ietf-httpbis-p1-messaging-latest (work in progress),
               June 2014.

NEW:

    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Message Syntax and Routing",
               RFC 7230, June 2014.


Section 8.1., paragraph 4:
OLD:

    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Semantics and Content",
               draft-ietf-httpbis-p2-semantics-latest (work in progress),
               June 2014.

NEW:

    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
               June 2014.


Section 8.1., paragraph 5:
OLD:

    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
               draft-ietf-httpbis-p6-cache-latest (work in progress),
               June 2014.

NEW:

    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
               RFC 7234, June 2014.


Section 1.2, paragraph 11:
OLD:

    4
       401 Unauthorized (status code)  7
       407 Proxy Authentication Required (status code)  7

NEW:

    4
       401 Unauthorized (status code)  6
       407 Proxy Authentication Required (status code)  6


Section 1.2, paragraph 12:
OLD:

    A
       Authorization header field  9

NEW:

    A
       Authorization header field  8


Section 1.2, paragraph 13:
OLD:

    C
       Canonical Root URI  6

NEW:

    C
       Canonical Root URI  5


Section 1.2, paragraph 14:
OLD:

    G
       Grammar
          auth-param  5
          auth-scheme  5
          Authorization  9
          challenge  5
          credentials  6
          Proxy-Authenticate  9
          Proxy-Authorization  10
          token68  5
          WWW-Authenticate  8

NEW:

    G
       Grammar
          auth-param  4
          auth-scheme  4
          Authorization  8
          challenge  4
          credentials  5
          Proxy-Authenticate  8
          Proxy-Authorization  9
          token68  4
          WWW-Authenticate  7


Section 1.2, paragraph 15:
OLD:

    P
       Protection Space  6
       Proxy-Authenticate header field  9
       Proxy-Authorization header field  10

NEW:

    P
       Protection Space  5
       Proxy-Authenticate header field  8
       Proxy-Authorization header field  9


Section 1.2, paragraph 16:
OLD:

    R
       Realm  6

NEW:

    R
       Realm  5


Section 1.2, paragraph 17:
OLD:

    W
       WWW-Authenticate header field  8

NEW:

    W
       WWW-Authenticate header field  7

