draft-ietf-httpauth-digest-15.txt   draft-ietf-httpauth-digest-16.txt 
HTTPAuth R. Shekh-Yusef, Ed. HTTPAuth R. Shekh-Yusef, Ed.
Internet-Draft Avaya Internet-Draft Avaya
Obsoletes: 2617 (if approved) D. Ahrens Obsoletes: 2617 (if approved) D. Ahrens
Intended status: Standards Track Independent Intended status: Standards Track Independent
Expires: September 6, 2015 S. Bremer Expires: October 5, 2015 S. Bremer
Netzkonform Netzkonform
March 5, 2015 April 3, 2015
HTTP Digest Access Authentication HTTP Digest Access Authentication
draft-ietf-httpauth-digest-15 draft-ietf-httpauth-digest-16
Abstract Abstract
HTTP provides a simple challenge-response authentication mechanism HTTP provides a simple challenge-response authentication mechanism
that may be used by a server to challenge a client request and by a that may be used by a server to challenge a client request and by a
client to provide authentication information. This document defines client to provide authentication information. This document defines
the HTTP Digest Authentication scheme that can be used with the HTTP the HTTP Digest Authentication scheme that can be used with the HTTP
authentication mechanism. authentication mechanism.
Editorial Note (To be removed by RFC Editor before publication) Editorial Note (To be removed by RFC Editor before publication)
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2015. This Internet-Draft will expire on October 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 20 skipping to change at page 3, line 20
5.4. Limited Use Nonce Values . . . . . . . . . . . . . . . . 22 5.4. Limited Use Nonce Values . . . . . . . . . . . . . . . . 22
5.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 22 5.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 22
5.6. Weakness Created by Multiple Authentication Schemes . . . 23 5.6. Weakness Created by Multiple Authentication Schemes . . . 23
5.7. Online dictionary attacks . . . . . . . . . . . . . . . . 24 5.7. Online dictionary attacks . . . . . . . . . . . . . . . . 24
5.8. Man in the Middle . . . . . . . . . . . . . . . . . . . . 24 5.8. Man in the Middle . . . . . . . . . . . . . . . . . . . . 24
5.9. Chosen plaintext attacks . . . . . . . . . . . . . . . . 25 5.9. Chosen plaintext attacks . . . . . . . . . . . . . . . . 25
5.10. Precomputed dictionary attacks . . . . . . . . . . . . . 25 5.10. Precomputed dictionary attacks . . . . . . . . . . . . . 25
5.11. Batch brute force attacks . . . . . . . . . . . . . . . . 25 5.11. Batch brute force attacks . . . . . . . . . . . . . . . . 25
5.12. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.12. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
6.1. HTTP Digest Hash Algorithms Registry . . . . . . . . . . 26 6.1. Hash Algorithms for HTTP Digest Authentication . . . . . 26
6.2. Digest Scheme Registration . . . . . . . . . . . . . . . 27 6.2. Digest Scheme Registration . . . . . . . . . . . . . . . 27
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . 28 8.1. Normative References . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . 29 8.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Changes from RFC 2617 . . . . . . . . . . . . . . . 30 Appendix A. Changes from RFC 2617 . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
skipping to change at page 26, line 26 skipping to change at page 26, line 26
possibility of replay. Others may satisfied with a nonce like the possibility of replay. Others may satisfied with a nonce like the
one recommended above restricted to a single IP address and a single one recommended above restricted to a single IP address and a single
ETag or with a limited lifetime. ETag or with a limited lifetime.
The bottom line is that *any* compliant implementation will be The bottom line is that *any* compliant implementation will be
relatively weak by cryptographic standards, but *any* compliant relatively weak by cryptographic standards, but *any* compliant
implementation will be far superior to Basic Authentication. implementation will be far superior to Basic Authentication.
6. IANA Considerations 6. IANA Considerations
6.1. HTTP Digest Hash Algorithms Registry 6.1. Hash Algorithms for HTTP Digest Authentication
This specification creates a new IANA registry named "HTTP Digest This specification creates a new IANA registry named "Hash Algorithms
Hash Algorithms". When registering a new hash algorithm, the for HTTP Digest Authentication". This registry lists the hash
following information MUST be provided: algorithms that can be used in HTTP Digest Authentication. When
registering a new hash algorithm, the following information MUST be
provided:
Hash Algorithm Hash Algorithm
The textual name of the hash algorithm. The textual name of the hash algorithm.
Digest Size Digest Size
The size of the algorithm's output in bits. The size of the algorithm's output in bits.
Reference Reference
A reference to the specification that describes the new algorithm. A reference to the specification adding the algorithm to this
registry.
The update policy for this registry shall be Specification Required. The update policy for this registry shall be Specification Required.
The initial registry will contain the following entries: The initial registry will contain the following entries:
+----------------+-------------+-----------+ +----------------+-------------+-----------+
| Hash Algorithm | Digest Size | Reference | | Hash Algorithm | Digest Size | Reference |
+----------------+-------------+-----------+ +----------------+-------------+-----------+
| "MD5" | 128 | RFC XXXX | | "MD5" | 128 | RFC XXXX |
| "SHA-512-256" | 256 | RFC XXXX | | "SHA-512-256" | 256 | RFC XXXX |
| "SHA-256" | 256 | RFC XXXX | | "SHA-256" | 256 | RFC XXXX |
+----------------+-------------+-----------+ +----------------+-------------+-----------+
Each one of the algorithms defined in the registry might have a -sess Each one of the algorithms defined in the registry might have a -sess
variant, e.g. MD5-sess, SHA-256-sess, etc. variant, e.g. MD5-sess, SHA-256-sess, etc.
6.2. Digest Scheme Registration 6.2. Digest Scheme Registration
This specification registers the Digest scheme with the This specification updates the Digest scheme in Hypertext Transfer
Authentication Scheme Registry. Protocol (HTTP) Authentication Scheme Registry.
Authentication Scheme Name: Digest Authentication Scheme Name: Digest
Pointer to specification text: this specification Pointer to specification text: this specification
7. Acknowledgments 7. Acknowledgments
The authors of this document would like to thank the authors of The authors of this document would like to thank the authors of
[RFC2617], as this document heavily borrows text from their document [RFC2617], as this document heavily borrows text from their document
to provide a complete description of the digest scheme and its to provide a complete description of the digest scheme and its
operations. operations.
Special thanks to Julian Reschke for his many reviews, comments, Special thanks to Julian Reschke for his many reviews, comments,
suggestions, and text provided to various areas in this document. suggestions, and text provided to various areas in this document.
The authors would like to thank Stephen Farrell, Yoav Nir, Phillip The authors would like to thank Stephen Farrell, Yoav Nir, Phillip
Hallam-Baker, Manu Sporny, Paul Hoffman, Yaron Sheffer, Sean Turner, Hallam-Baker, Manu Sporny, Paul Hoffman, Yaron Sheffer, Sean Turner,
Geoff Baskwill, Eric Cooper, Bjoern Hoehrmann, Martin Durst, Peter Geoff Baskwill, Eric Cooper, Bjoern Hoehrmann, Martin Durst, Peter
Saint-Andre, Michael Sweet, Daniel Stenberg, Brett Tate, Paul Leach, Saint-Andre, Michael Sweet, Daniel Stenberg, Brett Tate, Paul Leach,
Ilari Liusvaara, and Gary Mort, Alexey Melnikov, and Benjamin Kaduk Ilari Liusvaara, Gary Mort, Alexey Melnikov, and Benjamin Kaduk for
for their careful review and comments. their careful review and comments.
The authors would like to thank Jonathan Stoke, Nico Williams, Harry The authors would like to thank Jonathan Stoke, Nico Williams, Harry
Halpin, and Phil Hunt for their comments on the mailing list when Halpin, and Phil Hunt for their comments on the mailing list when
discussing various aspects of this document. discussing various aspects of this document.
The authors would like to thank Paul Kyzivat and Dale Worley for The authors would like to thank Paul Kyzivat and Dale Worley for
their careful review and feedback on some aspects of this document. their careful review and feedback on some aspects of this document.
The authors would like to thank Barry Leiba for his help with the
registry.
8. References 8. References
8.1. Normative References 8.1. Normative References
[AUTHINFO] [AUTHINFO]
Reschke, J., "The Hypertext Transfer Protocol (HTTP) Reschke, J., "The Hypertext Transfer Protocol (HTTP)
Authentication-Info and Proxy-Authentication-Info Response Authentication-Info and Proxy-Authentication-Info Response
Header Fields", draft-ietf-httpbis-auth-info-02 (work in Header Fields", draft-ietf-httpbis-auth-info-02 (work in
progress), February 2015. progress), February 2015.
 End of changes. 11 change blocks. 
14 lines changed or deleted 20 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/