draft-ietf-httpauth-basicauth-update-03.txt   draft-ietf-httpauth-basicauth-update-04.txt 
HTTPAuth Working Group J. Reschke HTTPAuth Working Group J. Reschke
Internet-Draft greenbytes Internet-Draft greenbytes
Obsoletes: 2617 (if approved) December 2, 2014 Obsoletes: 2617 (if approved) December 19, 2014
Intended status: Standards Track Intended status: Standards Track
Expires: June 5, 2015 Expires: June 22, 2015
The 'Basic' HTTP Authentication Scheme The 'Basic' HTTP Authentication Scheme
draft-ietf-httpauth-basicauth-update-03 draft-ietf-httpauth-basicauth-update-04
Abstract Abstract
This document defines the "Basic" Hypertext Transfer Protocol (HTTP) This document defines the "Basic" Hypertext Transfer Protocol (HTTP)
Authentication Scheme, which transmits credentials as userid/password Authentication Scheme, which transmits credentials as userid/password
pairs, obfuscated by the use of Base64 encoding. pairs, obfuscated by the use of Base64 encoding.
Editorial Note (To be removed by RFC Editor before publication) Editorial Note (To be removed by RFC Editor before publication)
Discussion of this draft takes place on the HTTPAuth working group Discussion of this draft takes place on the HTTPAuth working group
mailing list (http-auth@ietf.org), which is archived at <http:// mailing list (http-auth@ietf.org), which is archived at <http://
www.ietf.org/mail-archive/web/http-auth/current/maillist.html>. www.ietf.org/mail-archive/web/http-auth/current/maillist.html>.
XML versions, latest edits and the issues list for this document are XML versions, latest edits and the issues list for this document are
available from <http://greenbytes.de/tech/ available from <http://greenbytes.de/tech/
webdav/#draft-ietf-httpauth-basicauth-update>. webdav/#draft-ietf-httpauth-basicauth-update>.
The changes in this draft are summarized in Appendix C.4. The changes in this draft are summarized in Appendix C.5.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 5, 2015. This Internet-Draft will expire on June 22, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 19 skipping to change at page 3, line 19
1.1.1. Syntax Notation . . . . . . . . . . . . . . . . . . . 4 1.1.1. Syntax Notation . . . . . . . . . . . . . . . . . . . 4
2. The 'Basic' Authentication Scheme . . . . . . . . . . . . . . 4 2. The 'Basic' Authentication Scheme . . . . . . . . . . . . . . 4
2.1. The 'charset' auth-param . . . . . . . . . . . . . . . . . 6 2.1. The 'charset' auth-param . . . . . . . . . . . . . . . . . 6
2.2. Re-using Credentials . . . . . . . . . . . . . . . . . . . 8 2.2. Re-using Credentials . . . . . . . . . . . . . . . . . . . 8
3. Internationalization Considerations . . . . . . . . . . . . . 8 3. Internationalization Considerations . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Changes from RFC 2617 . . . . . . . . . . . . . . . . 12 Appendix A. Changes from RFC 2617 . . . . . . . . . . . . . . . . 12
Appendix B. Deployment Considerations for the 'charset' Appendix B. Deployment Considerations for the 'charset'
Parameter . . . . . . . . . . . . . . . . . . . . . . 12 Parameter . . . . . . . . . . . . . . . . . . . . . . 12
B.1. User Agents . . . . . . . . . . . . . . . . . . . . . . . 12 B.1. User Agents . . . . . . . . . . . . . . . . . . . . . . . 12
B.2. Origin Servers . . . . . . . . . . . . . . . . . . . . . . 13 B.2. Origin Servers . . . . . . . . . . . . . . . . . . . . . . 13
B.3. Why not simply switch the default encoding to UTF-8? . . . 13 B.3. Why not simply switch the default encoding to UTF-8? . . . 13
Appendix C. Change Log (to be removed by RFC Editor before Appendix C. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 13 publication) . . . . . . . . . . . . . . . . . . . . 13
C.1. Since RFC 2617 . . . . . . . . . . . . . . . . . . . . . . 13 C.1. Since RFC 2617 . . . . . . . . . . . . . . . . . . . . . . 13
C.2. Since draft-ietf-httpauth-basicauth-update-00 . . . . . . 13 C.2. Since draft-ietf-httpauth-basicauth-update-00 . . . . . . 13
C.3. Since draft-ietf-httpauth-basicauth-update-01 . . . . . . 14 C.3. Since draft-ietf-httpauth-basicauth-update-01 . . . . . . 14
C.4. Since draft-ietf-httpauth-basicauth-update-02 . . . . . . 14 C.4. Since draft-ietf-httpauth-basicauth-update-02 . . . . . . 14
C.5. Since draft-ietf-httpauth-basicauth-update-03 . . . . . . 14
1. Introduction 1. Introduction
This document defines the "Basic" Hypertext Transfer Protocol (HTTP) This document defines the "Basic" Hypertext Transfer Protocol (HTTP)
Authentication Scheme ([RFC7235]), which transmits credentials as Authentication Scheme, which transmits credentials as userid/password
userid/password pairs, obfuscated by the use of Base64 encoding. pairs, obfuscated by the use of Base64 encoding (HTTP authentication
schemes are defined in [RFC7235]).
This scheme is not considered to be a secure method of user This scheme is not considered to be a secure method of user
authentication unless used in conjunction with some external secure authentication unless used in conjunction with some external secure
system such as TLS (Transport Layer Security, [RFC5246]), as the user system such as TLS (Transport Layer Security, [RFC5246]), as the user
name and password are passed over the network as cleartext. name and password are passed over the network as cleartext.
The "Basic" scheme previously was defined in Section 2 of [RFC2617]. The "Basic" scheme previously was defined in Section 2 of [RFC2617].
This document updates the definition, and also addresses This document updates the definition, and also addresses
internationalization issues by introducing the "charset" internationalization issues by introducing the "charset"
authentication parameter (Section 2.1). authentication parameter (Section 2.1).
skipping to change at page 5, line 25 skipping to change at page 5, line 26
o the authentication parameter "charset" is OPTIONAL (see o the authentication parameter "charset" is OPTIONAL (see
Section 2.1) Section 2.1)
o no other authentication parameters are defined -- unknown o no other authentication parameters are defined -- unknown
parameters MUST be ignored by recipients, and new parameters can parameters MUST be ignored by recipients, and new parameters can
only be defined by revising this specification only be defined by revising this specification
Note that both scheme and parameter names are matched case- Note that both scheme and parameter names are matched case-
insensitively. insensitively.
For credentials, the "token-68" syntax defined in Section 2.2 of For credentials, the "token68" syntax defined in Section 2.1 of
[RFC7235] is used. The value is computed based on user-id and [RFC7235] is used. The value is computed based on user-id and
password as defined below. password as defined below.
Upon receipt of a request for a URI within the protection space that Upon receipt of a request for a URI within the protection space that
lacks credentials, the server can reply with a challenge using the lacks credentials, the server can reply with a challenge using the
401 (Unauthorized) status code ([RFC7235], Section 3.1) and the WWW- 401 (Unauthorized) status code ([RFC7235], Section 3.1) and the WWW-
Authenticate header field ([RFC7235], Section 4.1). Authenticate header field ([RFC7235], Section 4.1).
For instance: For instance:
skipping to change at page 5, line 48 skipping to change at page 6, line 4
WWW-Authenticate: Basic realm="WallyWorld" WWW-Authenticate: Basic realm="WallyWorld"
...where "WallyWorld" is the string assigned by the server to ...where "WallyWorld" is the string assigned by the server to
identify the protection space. identify the protection space.
A proxy can respond with a similar challenge using the 407 (Proxy A proxy can respond with a similar challenge using the 407 (Proxy
Authentication Required) status code ([RFC7235], Section 3.2) and the Authentication Required) status code ([RFC7235], Section 3.2) and the
Proxy-Authenticate header field ([RFC7235], Section 4.3). Proxy-Authenticate header field ([RFC7235], Section 4.3).
To receive authorization, the client To receive authorization, the client
1. obtains the userid and password from the user,
1. obtains userid and password from the user,
2. constructs the user-pass by concatenating userid, a single colon 2. constructs the user-pass by concatenating userid, a single colon
(":") character, and the password, (":") character, and the password,
3. encodes the user-pass into an octet sequence (see below for a 3. encodes the user-pass into an octet sequence (see below for a
discussion of character encoding schemes), discussion of character encoding schemes),
4. and obtains the basic-credentials by encoding this octet sequence 4. and obtains the basic-credentials by encoding this octet sequence
using base64 ([RFC4648], Section 4) into a sequence of US-ASCII using base64 ([RFC4648], Section 4) into a sequence of US-ASCII
characters ([USASCII]). characters ([RFC0020]).
The original definition of this authentication scheme failed to The original definition of this authentication scheme failed to
specify the character encoding scheme used to convert the user-pass specify the character encoding scheme used to convert the user-pass
into an octet sequence. In practice, most implementations chose into an octet sequence. In practice, most implementations chose
either a local-specific encoding such as ISO-8859-1 ([ISO-8859-1]), either a local-specific encoding such as ISO-8859-1 ([ISO-8859-1]),
or UTF-8 ([RFC3629]). For backwards compatibility reasons, this or UTF-8 ([RFC3629]). For backwards compatibility reasons, this
specification continues to leave the default encoding undefined, as specification continues to leave the default encoding undefined, as
long as it is compatible to US-ASCII (mapping any US-ASCII character long as it is compatible with US-ASCII (mapping any US-ASCII
to a single octet matching the US-ASCII character code). character to a single octet matching the US-ASCII character code).
Userid and password MUST NOT contain any control characters (see The userid and password MUST NOT contain any control characters (see
"CTL" in Appendix B.1 of [RFC5234]). "CTL" in Appendix B.1 of [RFC5234]).
Furthermore, a userid containing a colon character is invalid, as Furthermore, a userid containing a colon character is invalid, as
recipients will split the user-pass at the first occurence of a colon recipients will split the user-pass at the first occurence of a colon
character. Note that many user agents however will accept a colon in character. Note that many user agents however will accept a colon in
userid, thereby producing a user-pass string that recipients will userid, thereby producing a user-pass string that recipients will
likely treat in a way not intended by the user. likely treat in a way not intended by the user.
If the user agent wishes to send the userid "Aladdin" and password If the user agent wishes to send the userid "Aladdin" and password
"open sesame", it would use the following header field: "open sesame", it would use the following header field:
skipping to change at page 7, line 4 skipping to change at page 7, line 7
information is purely advisory. information is purely advisory.
The only allowed value is "UTF-8", to be matched case-insensitively The only allowed value is "UTF-8", to be matched case-insensitively
(see [RFC2978], Section 2.3). It indicates that the server expects (see [RFC2978], Section 2.3). It indicates that the server expects
character data to be converted to Unicode Normalization Form C character data to be converted to Unicode Normalization Form C
("NFC", see Section 3 of [RFC5198]) and to be encoded into octets ("NFC", see Section 3 of [RFC5198]) and to be encoded into octets
using the UTF-8 character encoding scheme ([RFC3629]). using the UTF-8 character encoding scheme ([RFC3629]).
For the userid, recipients MUST support all characters defined in the For the userid, recipients MUST support all characters defined in the
"UsernameCasePreserved" profile defined in in Section 3.3 of "UsernameCasePreserved" profile defined in in Section 3.3 of
[PRECIS], with the exception of the colon (":") character. [PRECIS], with the exception of the colon (":") character.
For the password, recipients MUST support all characters defined in For the password, recipients MUST support all characters defined in
the "Password" profile defined in in Section 4.2 of [PRECIS]. the "OpaqueString" profile defined in in Section 4.2 of [PRECIS].
Other values are reserved for future use. Other values are reserved for future use.
Note: The 'charset' is only defined on challenges, as "Basic" uses Note: The 'charset' is only defined on challenges, as "Basic" uses
a single token for credentials ('token68' syntax), thus the a single token for credentials ('token68' syntax), thus the
credentials syntax isn't extensible. credentials syntax isn't extensible.
Note: The name 'charset' has been chosen for consistency with Note: The name 'charset' has been chosen for consistency with
Section 2.1.1 of [RFC2831]. A better name would have been Section 2.1.1 of [RFC2831]. A better name would have been
'accept-charset', as it is not about the message it appears in, 'accept-charset', as it is not about the message it appears in,
skipping to change at page 8, line 48 skipping to change at page 8, line 48
Note that a URI can be part of multiple authentication scopes (such Note that a URI can be part of multiple authentication scopes (such
as "http://example.com/" and "http://example.com/docs/"). This as "http://example.com/" and "http://example.com/docs/"). This
specification does not define which of these should be treated with specification does not define which of these should be treated with
higher priority. higher priority.
3. Internationalization Considerations 3. Internationalization Considerations
User names or passwords containing characters outside the US-ASCII User names or passwords containing characters outside the US-ASCII
character repertoire will cause interoperability issues, unless both character repertoire will cause interoperability issues, unless both
communication partners agree on what character encoding scheme is to communication partners agree on what character encoding scheme is to
be used. Senders can use the new 'charset' parameter (Section 2.1) be used. Servers can use the new 'charset' parameter (Section 2.1)
to indicate a preference of "UTF-8", increasing the probability that to indicate a preference of "UTF-8", increasing the probability that
clients will switch to that encoding. clients will switch to that encoding.
The "realm" parameter carries data that can be considered textual, The "realm" parameter carries data that can be considered textual,
however [RFC7235] does not define a way to reliably transport non-US- however [RFC7235] does not define a way to reliably transport non-US-
ASCII characters. This is a known issue that would need to be ASCII characters. This is a known issue that would need to be
addressed in that specification. addressed in that specification.
4. Security Considerations 4. Security Considerations
The Basic authentication scheme is not a secure method of user The Basic authentication scheme is not a secure method of user
authentication, nor does it in any way protect the entity, which is authentication, nor does it in any way protect the entity, which is
transmitted in cleartext across the physical network used as the transmitted in cleartext across the physical network used as the
carrier. HTTP does not prevent the addition of enhancements (such as carrier. HTTP does not prevent the addition of enhancements (such as
schemes to use one-time passwords) to Basic authentication. schemes to use one-time passwords) to Basic authentication.
The most serious flaw in Basic authentication is that it results in The most serious flaw in Basic authentication is that it results in
the essentially cleartext transmission of the user's password over the cleartext transmission of the user's password over the physical
the physical network. Many other authentication schemes address this network. Many other authentication schemes address this problem.
problem.
Because Basic authentication involves the cleartext transmission of Because Basic authentication involves the cleartext transmission of
passwords it SHOULD NOT be used (without enhancements) to protect passwords it SHOULD NOT be used (without enhancements such as HTTPS
sensitive or valuable information. [RFC2818]) to protect sensitive or valuable information.
A common use of Basic authentication is for identification purposes A common use of Basic authentication is for identification purposes
-- requiring the user to provide a user name and password as a means -- requiring the user to provide a user name and password as a means
of identification, for example, for purposes of gathering accurate of identification, for example, for purposes of gathering accurate
usage statistics on a server. When used in this way it is tempting usage statistics on a server. When used in this way it is tempting
to think that there is no danger in its use if illicit access to the to think that there is no danger in its use if illicit access to the
protected documents is not a major concern. This is only correct if protected documents is not a major concern. This is only correct if
the server issues both user name and password to the users and in the server issues both user name and password to the users and in
particular does not allow the user to choose his or her own password. particular does not allow the user to choose his or her own password.
The danger arises because naive users frequently reuse a single The danger arises because naive users frequently reuse a single
skipping to change at page 10, line 44 skipping to change at page 10, line 43
text were borrowed. See Section 6 of [RFC2617] for further text were borrowed. See Section 6 of [RFC2617] for further
acknowledgements. acknowledgements.
The internationalization problem with respect to the character The internationalization problem with respect to the character
encoding scheme used for user-pass has been reported as a Mozilla bug encoding scheme used for user-pass has been reported as a Mozilla bug
back in the year 2000 (see back in the year 2000 (see
<https://bugzilla.mozilla.org/show_bug.cgi?id=41489> and also the <https://bugzilla.mozilla.org/show_bug.cgi?id=41489> and also the
more recent <https://bugzilla.mozilla.org/show_bug.cgi?id=656213>). more recent <https://bugzilla.mozilla.org/show_bug.cgi?id=656213>).
It was Andrew Clover's idea to address it using a new auth-param. It was Andrew Clover's idea to address it using a new auth-param.
We also thank the members of the HTTPAuth Working Group, namely We also thank the members of the HTTPAuth Working Group and other
Stephen Farrell, Bjoern Hoehrmann, Amos Jeffries, James Manger, reviewers, namely Stephen Farrell, Bjoern Hoehrmann, Kari Hurtta,
Kathleen Moriarty, Yaron Sheffer, Michael Sweet, and Martin Thomson Amos Jeffries, Benjamin Kaduk, James Manger, Kathleen Moriarty, Yaron
for feedback on this revision. Sheffer, Michael Sweet, and Martin Thomson for feedback on this
revision.
7. References 7. References
7.1. Normative References 7.1. Normative References
[DIGEST] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication",
draft-ietf-httpauth-digest-08 (work in progress),
August 2014.
[PRECIS] Saint-Andre, P. and A. Melnikov, "Preparation, [PRECIS] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Enforcement, and Comparison of Internationalized
Strings Representing Usernames and Passwords", Strings Representing Usernames and Passwords",
draft-ietf-precis-saslprepbis-11 (work in progress), draft-ietf-precis-saslprepbis-12 (work in progress),
November 2014. December 2014.
[RFC0020] Cerf, V., "ASCII format for network interchange",
RFC 20, October 1969.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000. Procedures", BCP 19, RFC 2978, October 2000.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
skipping to change at page 11, line 48 skipping to change at page 11, line 46
January 2008. January 2008.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365, Internationalization in the IETF", BCP 166, RFC 6365,
September 2011. September 2011.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication", Transfer Protocol (HTTP/1.1): Authentication",
RFC 7235, June 2014. RFC 7235, June 2014.
[USASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
7.2. Informative References 7.2. Informative References
[DIGEST] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication",
draft-ietf-httpauth-digest-09 (work in progress),
December 2014.
[ISO-8859-1] International Organization for Standardization, [ISO-8859-1] International Organization for Standardization,
"Information technology -- 8-bit single-byte coded "Information technology -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No. graphic character sets -- Part 1: Latin alphabet No.
1", ISO/IEC 8859-1:1998, 1998. 1", ISO/IEC 8859-1:1998, 1998.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence,
S., Leach, P., Luotonen, A., and L. Stewart, "HTTP S., Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication: Basic and Digest Access
Authentication", RFC 2617, June 1999. Authentication", RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication [RFC2831] Leach, P. and C. Newman, "Using Digest Authentication
as a SASL Mechanism", RFC 2831, May 2000. as a SASL Mechanism", RFC 2831, May 2000.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246, Security (TLS) Protocol Version 1.2", RFC 5246,
August 2008. August 2008.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
skipping to change at page 14, line 36 skipping to change at page 14, line 36
Add a note about colons in userid. Add a note about colons in userid.
Attempt to explain authentication scopes. Attempt to explain authentication scopes.
C.4. Since draft-ietf-httpauth-basicauth-update-02 C.4. Since draft-ietf-httpauth-basicauth-update-02
Reference draft-ietf-precis-saslprepbis for the set of characters Reference draft-ietf-precis-saslprepbis for the set of characters
that need to be supported in userids and passwords. that need to be supported in userids and passwords.
C.5. Since draft-ietf-httpauth-basicauth-update-03
Update reference for draft-ietf-precis-saslprepbis (which renames
"Password" to "OpaqueString").
Mention HTTPS as enhancement for securing the transmission of
credentials.
Update DIGEST reference and change it to informative.
Use RFC 20 as reference for ASCII.
Author's Address Author's Address
Julian F. Reschke Julian F. Reschke
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, NW 48155
Germany Germany
EMail: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
 End of changes. 26 change blocks. 
37 lines changed or deleted 51 lines changed or added

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