< draft-ietf-precis-saslprepbis-12.txt   draft-ietf-precis-saslprepbis-13.txt >
PRECIS P. Saint-Andre PRECIS P. Saint-Andre
Internet-Draft &yet Internet-Draft &yet
Obsoletes: 4013 (if approved) A. Melnikov Obsoletes: 4013 (if approved) A. Melnikov
Intended status: Standards Track Isode Ltd Intended status: Standards Track Isode Ltd
Expires: June 5, 2015 December 2, 2014 Expires: June 26, 2015 December 23, 2014
Preparation, Enforcement, and Comparison of Internationalized Strings Preparation, Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords Representing Usernames and Passwords
draft-ietf-precis-saslprepbis-12 draft-ietf-precis-saslprepbis-13
Abstract Abstract
This document describes methods for handling Unicode strings This document describes methods for handling Unicode strings
representing usernames and passwords. This document obsoletes RFC representing usernames and passwords. This document obsoletes RFC
4013. 4013.
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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 26, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Usernames . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Usernames . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 5 3.2. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 5
3.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 6 3.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 6
3.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 6 3.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 6
3.3. UsernameCasePreserved Profile . . . . . . . . . . . . . . 6 3.3. UsernameCasePreserved Profile . . . . . . . . . . . . . . 6
3.3.1. Preparation . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. Preparation . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 7 3.3.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 7
skipping to change at page 2, line 29 skipping to change at page 2, line 29
3.4. Case Mapping vs. Case Preservation . . . . . . . . . . . 7 3.4. Case Mapping vs. Case Preservation . . . . . . . . . . . 7
3.5. Application-Layer Constructs . . . . . . . . . . . . . . 9 3.5. Application-Layer Constructs . . . . . . . . . . . . . . 9
3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. OpaqueString Profile . . . . . . . . . . . . . . . . . . 11 4.2. OpaqueString Profile . . . . . . . . . . . . . . . . . . 11
4.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 12 4.2.1. Preparation . . . . . . . . . . . . . . . . . . . . . 12
4.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 12 4.2.2. Enforcement . . . . . . . . . . . . . . . . . . . . . 12
4.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 12 4.2.3. Comparison . . . . . . . . . . . . . . . . . . . . . 12
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Use in Application Protocols . . . . . . . . . . . . . . . . 13
5.1. Usernames . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Usernames . . . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.2. UsernameCasePreserved Profile . . . . . . . . . . . . . . 16 7.1. UsernameCaseMapped Profile . . . . . . . . . . . . . . . 16
6.3. OpaqueString Profile . . . . . . . . . . . . . . . . . . 17 7.2. UsernameCasePreserved Profile . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7.3. OpaqueString Profile . . . . . . . . . . . . . . . . . . 18
7.1. Password/Passphrase Strength . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7.2. Identifier Comparison . . . . . . . . . . . . . . . . . . 18 8.1. Password/Passphrase Strength . . . . . . . . . . . . . . 18
7.3. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 18 8.2. Identifier Comparison . . . . . . . . . . . . . . . . . . 18
7.4. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 18 8.3. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.4. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Differences from RFC 4013 . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 21 Appendix A. Differences from RFC 4013 . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Usernames and passwords are widely used for authentication and Usernames and passwords are widely used for authentication and
authorization on the Internet, either directly when provided in authorization on the Internet, either directly when provided in
plaintext (as in the SASL PLAIN mechanism [RFC4616] or the HTTP Basic plaintext (as in the SASL PLAIN mechanism [RFC4616] or the HTTP Basic
scheme [RFC2617] / [I-D.ietf-httpauth-basicauth-update]) or scheme [RFC2617] / [I-D.ietf-httpauth-basicauth-update]) or
indirectly when provided as the input to a cryptographic algorithm indirectly when provided as the input to a cryptographic algorithm
such as a hash function (as in the SASL SCRAM mechanism [RFC5802] or such as a hash function (as in the SASL SCRAM mechanism [RFC5802] or
the HTTP Digest scheme [RFC2617] / [I-D.ietf-httpauth-digest]). the HTTP Digest scheme [RFC2617] / [I-D.ietf-httpauth-digest]).
skipping to change at page 13, line 46 skipping to change at page 13, line 46
+------------------------------------+------------------------------+ +------------------------------------+------------------------------+
| # | Password | Notes | | # | Password | Notes |
+------------------------------------+------------------------------+ +------------------------------------+------------------------------+
| 16| <foo&#x1680;bar> | Non-ASCII space (here, OGHAM | | 16| <foo&#x1680;bar> | Non-ASCII space (here, OGHAM |
| | | SPACE MARK, U+1680) is not | | | | SPACE MARK, U+1680) is not |
| | | allowed | | | | allowed |
+------------------------------------+------------------------------+ +------------------------------------+------------------------------+
| 17| <my cat is a &#x9;by> | Controls are disallowed | | 17| <my cat is a &#x9;by> | Controls are disallowed |
+------------------------------------+------------------------------+ +------------------------------------+------------------------------+
5. Migration 5. Use in Application Protocols
This specification defines only the PRECIS-based rules for handling
of strings conforming to the UsernameCaseMapped and
UsernameCasePreserved profiles of the PRECIS IdentifierClass, and
strings conforming to the OpaqueString profile of the PRECIS
FreeformClass. It is the responsibility of an application protocol
to specify the protocol slots in which such strings can appear, the
entities that are expected to enforce the rules governing such
strings, and when in protocol processing or interface handling the
rules need to be enforced. See Section 6 of
[I-D.ietf-precis-framework] for guidelines about using PRECIS
profiles in applications.
Above and beyond the PRECIS-based rules specified here, application
protocols can also define application-specific rules governing such
strings (rules regarding minimum or maximum length, further
restrictions on allowable characters or character ranges, safeguards
to mitigate the effects of visually similar characters, etc.),
application-layer constructs (see Section 3.5), and related matters.
Some PRECIS profile definitions encourage entities that enforce the
rules to be liberal in what they accept. However, for usernames and
passwords such a policy can be problematic since it can lead to false
positives. An in-depth discussion can be found in "Issues in
Identifier Comparison for Security Purposes" [RFC6943].
6. Migration
The rules defined in this specification differ slightly from those The rules defined in this specification differ slightly from those
defined by the SASLprep specification [RFC4013]. The following defined by the SASLprep specification [RFC4013]. The following
sections describe these differences, along with their implications sections describe these differences, along with their implications
for migration, in more detail. for migration, in more detail.
5.1. Usernames 6.1. Usernames
Deployments that currently use SASLprep for handling usernames might Deployments that currently use SASLprep for handling usernames might
need to scrub existing data when migrating to use of the rules need to scrub existing data when migrating to use of the rules
defined in this specification. In particular: defined in this specification. In particular:
o SASLprep specified the use of Unicode Normalization Form KC o SASLprep specified the use of Unicode Normalization Form KC
(NFKC), whereas the UsernameCaseMapped and UsernameCasePreserved (NFKC), whereas the UsernameCaseMapped and UsernameCasePreserved
profiles employ Unicode Normalization Form C (NFC). In practice profiles employ Unicode Normalization Form C (NFC). In practice
this change is unlikely to cause significant problems, because this change is unlikely to cause significant problems, because
NFKC provides methods for mapping Unicode code points with NFKC provides methods for mapping Unicode code points with
skipping to change at page 15, line 14 skipping to change at page 15, line 41
o SASLprep allowed uppercase and titlecase characters, whereas the o SASLprep allowed uppercase and titlecase characters, whereas the
UsernameCaseMapped profile maps uppercase and titlecase characters UsernameCaseMapped profile maps uppercase and titlecase characters
to their lowercase equivalents (by contrast, the to their lowercase equivalents (by contrast, the
UsernameCasePreserved profile matches SASLprep in this regard). UsernameCasePreserved profile matches SASLprep in this regard).
For migration purposes, deployments can either use the For migration purposes, deployments can either use the
UsernameCaseMapped profile (thus losing the case information) or UsernameCaseMapped profile (thus losing the case information) or
use the UsernameCasePreserved profile (thus ignoring case use the UsernameCasePreserved profile (thus ignoring case
difference when comparing usernames). difference when comparing usernames).
5.2. Passwords 6.2. Passwords
Depending on local service policy, migration from RFC 4013 to this Depending on local service policy, migration from RFC 4013 to this
specification might not involve any scrubbing of data (since specification might not involve any scrubbing of data (since
passwords might not be stored in the clear anyway); however, service passwords might not be stored in the clear anyway); however, service
providers need to be aware of possible issues that might arise during providers need to be aware of possible issues that might arise during
migration. In particular: migration. In particular:
o SASLprep specified the use of Unicode Normalization Form KC o SASLprep specified the use of Unicode Normalization Form KC
(NFKC), whereas the OpaqueString profile employs Unicode (NFKC), whereas the OpaqueString profile employs Unicode
Normalization Form C (NFC). Because NFKC is more aggressive about Normalization Form C (NFC). Because NFKC is more aggressive about
skipping to change at page 16, line 10 skipping to change at page 16, line 37
Appendix B.1 of [RFC3454]) to nothing, whereas the PRECIS Appendix B.1 of [RFC3454]) to nothing, whereas the PRECIS
FreeformClass entirely disallows such characters, which correspond FreeformClass entirely disallows such characters, which correspond
to the code points from the "M" category defined under to the code points from the "M" category defined under
Section 8.13 of [I-D.ietf-precis-framework] (with the exception of Section 8.13 of [I-D.ietf-precis-framework] (with the exception of
U+1806 MONGOLIAN TODO SOFT HYPHEN, which was commonly mapped to U+1806 MONGOLIAN TODO SOFT HYPHEN, which was commonly mapped to
nothing in Unicode 3.2 but at the time of this writing is allowed nothing in Unicode 3.2 but at the time of this writing is allowed
by Unicode 7.0). In practice, this change will probably have no by Unicode 7.0). In practice, this change will probably have no
effect on comparison, but user-oriented software might reject such effect on comparison, but user-oriented software might reject such
code points instead of ignoring them during password preparation. code points instead of ignoring them during password preparation.
6. IANA Considerations 7. IANA Considerations
The IANA shall add the following entries to the PRECIS Profiles The IANA shall add the following entries to the PRECIS Profiles
Registry. Registry.
6.1. UsernameCaseMapped Profile 7.1. UsernameCaseMapped Profile
Name: UsernameCaseMapped. Name: UsernameCaseMapped.
Base Class: IdentifierClass. Base Class: IdentifierClass.
Applicability: Usernames in security and application protocols. Applicability: Usernames in security and application protocols.
Replaces: The SASLprep profile of Stringprep. Replaces: The SASLprep profile of Stringprep.
Width Mapping Rule: Map fullwidth and halfwidth characters to their Width Mapping Rule: Map fullwidth and halfwidth characters to their
skipping to change at page 16, line 43 skipping to change at page 17, line 23
Normalization Rule: NFC. Normalization Rule: NFC.
Directionality Rule: The "Bidi Rule" defined in RFC 5893 applies. Directionality Rule: The "Bidi Rule" defined in RFC 5893 applies.
Enforcement: To be defined by security or application protocols that Enforcement: To be defined by security or application protocols that
use this profile. use this profile.
Specification: RFC XXXX. [Note to RFC Editor: please change XXXX to Specification: RFC XXXX. [Note to RFC Editor: please change XXXX to
the number issued for this specification.] the number issued for this specification.]
6.2. UsernameCasePreserved Profile 7.2. UsernameCasePreserved Profile
Name: UsernameCasePreserved. Name: UsernameCasePreserved.
Base Class: IdentifierClass. Base Class: IdentifierClass.
Applicability: Usernames in security and application protocols. Applicability: Usernames in security and application protocols.
Replaces: The SASLprep profile of Stringprep. Replaces: The SASLprep profile of Stringprep.
Width Mapping Rule: Map fullwidth and halfwidth characters to their Width Mapping Rule: Map fullwidth and halfwidth characters to their
skipping to change at page 17, line 22 skipping to change at page 18, line 5
Normalization Rule: NFC. Normalization Rule: NFC.
Directionality Rule: The "Bidi Rule" defined in RFC 5893 applies. Directionality Rule: The "Bidi Rule" defined in RFC 5893 applies.
Enforcement: To be defined by security or application protocols that Enforcement: To be defined by security or application protocols that
use this profile. use this profile.
Specification: RFC XXXX. [Note to RFC Editor: please change XXXX to Specification: RFC XXXX. [Note to RFC Editor: please change XXXX to
the number issued for this specification.] the number issued for this specification.]
6.3. OpaqueString Profile 7.3. OpaqueString Profile
Name: OpaqueString. Name: OpaqueString.
Base Class: FreeformClass. Base Class: FreeformClass.
Applicability: Passwords and other opaque strings in security and Applicability: Passwords and other opaque strings in security and
application protocols. application protocols.
Replaces: The SASLprep profile of Stringprep. Replaces: The SASLprep profile of Stringprep.
skipping to change at page 18, line 5 skipping to change at page 18, line 33
Normalization Rule: NFC. Normalization Rule: NFC.
Directionality Rule: None. Directionality Rule: None.
Enforcement: To be defined by security or application protocols that Enforcement: To be defined by security or application protocols that
use this profile. use this profile.
Specification: RFC XXXX. [Note to RFC Editor: please change XXXX to Specification: RFC XXXX. [Note to RFC Editor: please change XXXX to
the number issued for this specification.] the number issued for this specification.]
7. Security Considerations 8. Security Considerations
7.1. Password/Passphrase Strength 8.1. Password/Passphrase Strength
The ability to include a wide range of characters in passwords and The ability to include a wide range of characters in passwords and
passphrases can increase the potential for creating a strong password passphrases can increase the potential for creating a strong password
with high entropy. However, in practice, the ability to include such with high entropy. However, in practice, the ability to include such
characters ought to be weighed against the possible need to reproduce characters ought to be weighed against the possible need to reproduce
them on various devices using various input methods. them on various devices using various input methods.
7.2. Identifier Comparison 8.2. Identifier Comparison
The process of comparing identifiers (such as SASL simple user names, The process of comparing identifiers (such as SASL simple user names,
authentication identifiers, and authorization identifiers) can lead authentication identifiers, and authorization identifiers) can lead
to either false negatives or false positives, both of which have to either false negatives or false positives, both of which have
security implications. A more detailed discussion can be found in security implications. A more detailed discussion can be found in
[RFC6943]. [RFC6943].
7.3. Reuse of PRECIS 8.3. Reuse of PRECIS
The security considerations described in [I-D.ietf-precis-framework] The security considerations described in [I-D.ietf-precis-framework]
apply to the "IdentifierClass" and "FreeformClass" base string apply to the "IdentifierClass" and "FreeformClass" base string
classes used in this document for usernames and passwords, classes used in this document for usernames and passwords,
respectively. respectively.
7.4. Reuse of Unicode 8.4. Reuse of Unicode
The security considerations described in [UTS39] apply to the use of The security considerations described in [UTS39] apply to the use of
Unicode characters in usernames and passwords. Unicode characters in usernames and passwords.
8. References 9. References
8.1. Normative References 9.1. Normative References
[I-D.ietf-precis-framework] [I-D.ietf-precis-framework]
Saint-Andre, P. and M. Blanchet, "Precis Framework: Saint-Andre, P. and M. Blanchet, "Precis Framework:
Handling Internationalized Strings in Protocols", draft- Handling Internationalized Strings in Protocols", draft-
ietf-precis-framework-20 (work in progress), November ietf-precis-framework-21 (work in progress), December
2014. 2014.
[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.
[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.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
6.3", 2013, 6.3", 2013,
<http://www.unicode.org/versions/Unicode6.3.0/>. <http://www.unicode.org/versions/Unicode6.3.0/>.
8.2. Informative References 9.2. Informative References
[I-D.ietf-httpauth-basicauth-update] [I-D.ietf-httpauth-basicauth-update]
Reschke, J., "The 'Basic' HTTP Authentication Scheme", Reschke, J., "The 'Basic' HTTP Authentication Scheme",
draft-ietf-httpauth-basicauth-update-03 (work in draft-ietf-httpauth-basicauth-update-04 (work in
progress), December 2014. progress), December 2014.
[I-D.ietf-httpauth-digest] [I-D.ietf-httpauth-digest]
Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest
Access Authentication", draft-ietf-httpauth-digest-08 Access Authentication", draft-ietf-httpauth-digest-09
(work in progress), August 2014. (work in progress), December 2014.
[I-D.ietf-radext-nai] [I-D.ietf-radext-nai]
DeKok, A., "The Network Access Identifier", draft-ietf- DeKok, A., "The Network Access Identifier", draft-ietf-
radext-nai-11 (work in progress), November 2014. radext-nai-15 (work in progress), December 2014.
[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,
October 1969. October 1969.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
 End of changes. 24 change blocks. 
42 lines changed or deleted 70 lines changed or added

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