draft-ietf-httpauth-scram-auth-13.txt   draft-ietf-httpauth-scram-auth-14.txt 
HTTPAUTH A. Melnikov HTTPAUTH A. Melnikov
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Intended status: Experimental November 30, 2015 Intended status: Experimental December 5, 2015
Expires: June 2, 2016 Expires: June 7, 2016
Salted Challenge Response (SCRAM) HTTP Authentication Mechanism Salted Challenge Response (SCRAM) HTTP Authentication Mechanism
draft-ietf-httpauth-scram-auth-13.txt draft-ietf-httpauth-scram-auth-14.txt
Abstract Abstract
The authentication mechanism most widely deployed and used by
Internet application protocols is the transmission of clear-text
passwords over a channel protected by Transport Layer Security (TLS).
There are some significant security concerns with that mechanism,
which could be addressed by the use of a challenge response
authentication mechanism protected by TLS. Unfortunately, the HTTP
Digest challenge response mechanism presently on the standards track
failed widespread deployment, and have had success only in limited
use.
This specification describes a family of HTTP authentication This specification describes a family of HTTP authentication
mechanisms called the Salted Challenge Response Authentication mechanisms called the Salted Challenge Response Authentication
Mechanism (SCRAM), which addresses security concerns with HTTP Digest Mechanism (SCRAM), which provides a more robust authentication
and meets the deployability requirements. When used in combination mechanism than a plaintext password protected by Transport Layer
with TLS or an equivalent security layer, a mechanism from this Security (TLS) and avoids the deployment obstacles presented by
family could improve the status-quo for HTTP authentication. earlier TLS-protected challenge response authentication mechanisms.
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 2, 2016. This Internet-Draft will expire on June 7, 2016.
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
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. Conventions Used in This Document . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 5 3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . . . . 5
4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 6 4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . . . . . 6
5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7 5. SCRAM Authentication Exchange . . . . . . . . . . . . . . . . 7
5.1. One round trip reauthentication . . . . . . . . . . . . . . 10 5.1. One round trip reauthentication . . . . . . . . . . . . . . 10
6. Use of Authentication-Info header field with SCRAM . . . . . 12 6. Use of Authentication-Info header field with SCRAM . . . . . 12
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. Design Motivations . . . . . . . . . . . . . . . . . . . . . 15 11. Design Motivations . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Conventions Used in This Document 1. Introduction
The authentication mechanism most widely deployed and used by
Internet application protocols is the transmission of clear-text
passwords over a channel protected by Transport Layer Security (TLS).
There are some significant security concerns with that mechanism,
which could be addressed by the use of a challenge response
authentication mechanism protected by TLS. Unfortunately, the HTTP
Digest challenge response mechanism presently on the standards track
failed widespread deployment, and have had success only in limited
use.
This specification describes a family of authentication mechanisms
called the Salted Challenge Response Authentication Mechanism (SCRAM)
which addresses the requirements necessary to deploy a challenge-
response mechanism more widely than past attempts (see [RFC5802]).
In particular, it addresses some of the issues identified with HTTP
Digest [RFC6331], such as complexity of implementing and protection
of the whole authentication exchange in order to protect from certain
man-in-the-middle attacks.
HTTP SCRAM is adoptation of [RFC5802] for use in HTTP. (SCRAM data
exchanged is identical to what is defined in [RFC5802].) It also
adds 1 round trip reauthentication mode.
HTTP SCRAM provides the following protocol features:
o The authentication information stored in the authentication
database is not sufficient by itself (without a dictionary attack)
to impersonate the client. The information is salted to prevent a
pre-stored dictionary attack if the database is stolen.
o The server does not gain the ability to impersonate the client to
other servers (with an exception for server-authorized proxies).
o The mechanism permits the use of a server-authorized proxy without
requiring that proxy to have super-user rights with the back-end
server.
o Mutual authentication is supported, but only the client is named
(i.e., the server has no name).
2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Formal syntax is defined by [RFC5234] including the core rules Formal syntax is defined by [RFC5234] including the core rules
defined in Appendix B of [RFC5234]. defined in Appendix B of [RFC5234].
Example lines prefaced by "C:" are sent by the client and ones Example lines prefaced by "C:" are sent by the client and ones
prefaced by "S:" by the server. If a single "C:" or "S:" label prefaced by "S:" by the server. If a single "C:" or "S:" label
applies to multiple lines, then the line breaks between those lines applies to multiple lines, then the line breaks between those lines
are for editorial clarity only, and are not part of the actual are for editorial clarity only, and are not part of the actual
protocol exchange. protocol exchange.
1.1. Terminology 2.1. Terminology
This document uses several terms defined in [RFC4949] ("Internet This document uses several terms defined in [RFC4949] ("Internet
Security Glossary") including the following: authentication, Security Glossary") including the following: authentication,
authentication exchange, authentication information, brute force, authentication exchange, authentication information, brute force,
challenge-response, cryptographic hash function, dictionary attack, challenge-response, cryptographic hash function, dictionary attack,
eavesdropping, hash result, keyed hash, man-in-the-middle, nonce, eavesdropping, hash result, keyed hash, man-in-the-middle, nonce,
one-way encryption function, password, replay attack and salt. one-way encryption function, password, replay attack and salt.
Readers not familiar with these terms should use that glossary as a Readers not familiar with these terms should use that glossary as a
reference. reference.
skipping to change at page 3, line 29 skipping to change at page 4, line 10
o Authentication information: Information used to verify an identity o Authentication information: Information used to verify an identity
claimed by a SCRAM client. The authentication information for a claimed by a SCRAM client. The authentication information for a
SCRAM identity consists of salt, iteration count, the "StoredKey" SCRAM identity consists of salt, iteration count, the "StoredKey"
and "ServerKey" (as defined in the algorithm overview) for each and "ServerKey" (as defined in the algorithm overview) for each
supported cryptographic hash function. supported cryptographic hash function.
o Authentication database: The database used to look up the o Authentication database: The database used to look up the
authentication information associated with a particular identity. authentication information associated with a particular identity.
For application protocols, LDAPv3 (see [RFC4510]) is frequently For application protocols, LDAPv3 (see [RFC4510]) is frequently
used as the authentication database. For network-level protocols used as the authentication database. For lower-layer protocols
such as PPP or 802.11x, the use of RADIUS [RFC2865] is more such as PPP or 802.11x, the use of RADIUS [RFC2865] is more
common. common.
o Base64: An encoding mechanism defined in Section 4 of [RFC4648] o Base64: An encoding mechanism defined in Section 4 of [RFC4648]
which converts an octet string input to a textual output string which converts an octet string input to a textual output string
which can be easily displayed to a human. The use of base64 in which can be easily displayed to a human. The use of base64 in
SCRAM is restricted to the canonical form with no whitespace. SCRAM is restricted to the canonical form with no whitespace.
o Octet: An 8-bit byte. o Octet: An 8-bit byte.
o Octet string: A sequence of 8-bit bytes. o Octet string: A sequence of 8-bit bytes.
o Salt: A random octet string that is combined with a password o Salt: A random octet string that is combined with a password
before applying a one-way encryption function. This value is used before applying a one-way encryption function. This value is used
to protect passwords that are stored in an authentication to protect passwords that are stored in an authentication
database. database.
1.2. Notation 2.2. Notation
The pseudocode description of the algorithm uses the following The pseudocode description of the algorithm uses the following
notations: notations:
o ":=": The variable on the left hand side represents the octet o ":=": The variable on the left hand side represents the octet
string resulting from the expression on the right hand side. string resulting from the expression on the right hand side.
o "+": Octet string concatenation. o "+": Octet string concatenation.
o "[ ]": A portion of an expression enclosed in "[" and "]" may not o "[ ]": A portion of an expression enclosed in "[" and "]" may not
skipping to change at page 5, line 9 skipping to change at page 5, line 36
Hi := U1 XOR U2 XOR ... XOR Ui Hi := U1 XOR U2 XOR ... XOR Ui
where "i" is the iteration count, "+" is the string concatenation where "i" is the iteration count, "+" is the string concatenation
operator and INT(g) is a four-octet encoding of the integer g, operator and INT(g) is a four-octet encoding of the integer g,
most significant octet first. most significant octet first.
Hi() is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and Hi() is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and
with dkLen == output length of HMAC() == output length of H(). with dkLen == output length of HMAC() == output length of H().
2. Introduction
This specification describes a family of authentication mechanisms
called the Salted Challenge Response Authentication Mechanism (SCRAM)
which addresses the requirements necessary to deploy a challenge-
response mechanism more widely than past attempts (see [RFC5802]).
When used in combination with Transport Layer Security (TLS, see
[RFC5246]) or an equivalent security layer, a mechanism from this
family could improve the status-quo for HTTP authentication.
HTTP SCRAM is adoptation of [RFC5802] for use in HTTP. (SCRAM data
exchanged is identical to what is defined in [RFC5802].) It also
adds 1 round trip reauthentication mode.
HTTP SCRAM provides the following protocol features:
o The authentication information stored in the authentication
database is not sufficient by itself (without a dictionary attack)
to impersonate the client. The information is salted to prevent a
pre-stored dictionary attack if the database is stolen.
o The server does not gain the ability to impersonate the client to
other servers (with an exception for server-authorized proxies).
o The mechanism permits the use of a server-authorized proxy without
requiring that proxy to have super-user rights with the back-end
server.
o Mutual authentication is supported, but only the client is named
(i.e., the server has no name).
3. SCRAM Algorithm Overview 3. SCRAM Algorithm Overview
The following is a description of a full HTTP SCRAM authentication The following is a description of a full HTTP SCRAM authentication
exchange. Note that this section omits some details, such as client exchange. Note that this section omits some details, such as client
and server nonces. See Section 5 for more details. and server nonces. See Section 5 for more details.
To begin with, the SCRAM client is in possession of a username and To begin with, the SCRAM client is in possession of a username and
password (*) (or a ClientKey/ServerKey, or SaltedPassword). It sends password (*) (or a ClientKey/ServerKey, or SaltedPassword). It sends
the username to the server, which retrieves the corresponding the username to the server, which retrieves the corresponding
authentication information, i.e. a salt, StoredKey, ServerKey and the authentication information, i.e. a salt, StoredKey, ServerKey and the
iteration count i. (Note that a server implementation may choose to iteration count i. (Note that a server implementation may choose to
use the same iteration count for all accounts.) The server sends the use the same iteration count for all accounts.) The server sends the
salt and the iteration count to the client, which then computes the salt and the iteration count to the client, which then computes the
following values and sends a ClientProof to the server: following values and sends a ClientProof to the server:
(*) - Note that both the username and the password MUST be encoded in (*) - Note that both the username and the password MUST be encoded in
UTF-8 [RFC3629]. UTF-8 [RFC3629].
Informative Note: Implementors are encouraged to create test cases Informative Note: Implementors are encouraged to create test cases
that use both username passwords with non-ASCII codepoints. In that use both username passwords with non-ASCII codepoints. In
particular, it's useful to test codepoints whose "Unicode particular, it is useful to test codepoints whose "Unicode
Normalization Form C" and "Unicode Normalization Form KC" are Normalization Form C" and "Unicode Normalization Form KC" are
different. Some examples of such codepoints include Vulgar Fraction different. Some examples of such codepoints include Vulgar Fraction
One Half (U+00BD) and Acute Accent (U+00B4). One Half (U+00BD) and Acute Accent (U+00B4).
SaltedPassword := Hi(Normalize(password), salt, i) SaltedPassword := Hi(Normalize(password), salt, i)
ClientKey := HMAC(SaltedPassword, "Client Key") ClientKey := HMAC(SaltedPassword, "Client Key")
StoredKey := H(ClientKey) StoredKey := H(ClientKey)
AuthMessage := client-first-message-bare + "," + AuthMessage := client-first-message-bare + "," +
server-first-message + "," + server-first-message + "," +
client-final-message-without-proof client-final-message-without-proof
skipping to change at page 9, line 38 skipping to change at page 9, line 38
bindings, so this header always starts with "n"; otherwise the bindings, so this header always starts with "n"; otherwise the
message is invalid and authentication MUST fail. message is invalid and authentication MUST fail.
* SCRAM username and a random, unique nonce attributes. * SCRAM username and a random, unique nonce attributes.
In HTTP response, the server sends WWW-Authenticate header field In HTTP response, the server sends WWW-Authenticate header field
containing: a unique session identifier (the "sid" attribute) plus containing: a unique session identifier (the "sid" attribute) plus
the "data" attribute containing base64-encoded "server-first-message" the "data" attribute containing base64-encoded "server-first-message"
[RFC5802]. The "server-first-message" contains the user's iteration [RFC5802]. The "server-first-message" contains the user's iteration
count i, the user's salt, and the nonce with a concatenation of the count i, the user's salt, and the nonce with a concatenation of the
client-specified one with a server nonce. client-specified one (taken from the "client-first-message") with a
freshly generated server nonce.
The client then responds with another HTTP request with the The client then responds with another HTTP request with the
Authorization header field, which includes the "sid" attribute Authorization header field, which includes the "sid" attribute
received in the previous server response, together with the "data" received in the previous server response, together with the "data"
attribute containing base64-encoded "client-final-message" data. The attribute containing base64-encoded "client-final-message" data. The
latter has the same nonce and a ClientProof computed using the latter has the same nonce as in "server-first-message" and a
selected hash function (e.g. SHA-256) as explained earlier. ClientProof computed using the selected hash function (e.g. SHA-256)
as explained earlier.
The server verifies the nonce and the proof, and, finally, it The server verifies the nonce and the proof, and, finally, it
responds with a 200 HTTP response with the Authentication-Info header responds with a 200 HTTP response with the Authentication-Info header
field [RFC7615] containing the "sid" attribute (as received from the field [RFC7615] containing the "sid" attribute (as received from the
client) and the "data" attribute containing base64-encoded "server- client) and the "data" attribute containing base64-encoded "server-
final-message", concluding the authentication exchange. final-message", concluding the authentication exchange.
The client then authenticates the server by computing the The client then authenticates the server by computing the
ServerSignature and comparing it to the value sent by the server. If ServerSignature and comparing it to the value sent by the server. If
the two are different, the client MUST consider the authentication the two are different, the client MUST consider the authentication
skipping to change at page 12, line 14 skipping to change at page 12, line 48
6. Use of Authentication-Info header field with SCRAM 6. Use of Authentication-Info header field with SCRAM
When used with SCRAM, the Authentication-Info header field is allowed When used with SCRAM, the Authentication-Info header field is allowed
in the trailer of an HTTP message transferred via chunked transfer- in the trailer of an HTTP message transferred via chunked transfer-
coding. coding.
7. Formal Syntax 7. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC5234]. The "UTF8-2", Form (ABNF) notation as specified in [RFC5234].
"UTF8-3" and "UTF8-4" non-terminals are defined in [RFC3629].
ALPHA = <as defined in RFC 5234 appendix B.1> ALPHA = <as defined in RFC 5234 appendix B.1>
DIGIT = <as defined in RFC 5234 appendix B.1> DIGIT = <as defined in RFC 5234 appendix B.1>
base64-char = ALPHA / DIGIT / "/" / "+" base64-char = ALPHA / DIGIT / "/" / "+"
base64-4 = 4base64-char base64-4 = 4base64-char
base64-3 = 3base64-char "=" base64-3 = 3base64-char "="
skipping to change at page 14, line 40 skipping to change at page 14, line 40
negotiation is left to the HTTP authentication mechanism negotiation. negotiation is left to the HTTP authentication mechanism negotiation.
It is important that clients be able to sort a locally available list It is important that clients be able to sort a locally available list
of mechanisms by preference so that the client may pick the most of mechanisms by preference so that the client may pick the most
preferred of a server's advertised mechanism list. This preference preferred of a server's advertised mechanism list. This preference
order is not specified here as it is a local matter. The preference order is not specified here as it is a local matter. The preference
order should include objective and subjective notions of mechanism order should include objective and subjective notions of mechanism
cryptographic strength (e.g., SCRAM with a successor to SHA-1 may be cryptographic strength (e.g., SCRAM with a successor to SHA-1 may be
preferred over SCRAM with SHA-1). preferred over SCRAM with SHA-1).
A hostile server can perform a computational denial-of-service attack A hostile server can perform a computational denial-of-service attack
on clients by sending a big iteration count value. on clients by sending a big iteration count value. In order to
defend against that, a client implementation can pick a maximum
iteration count that it is willing to use, and that it rejects any
values that exceed that threshold (in such cases the client, of
course, has to fail the authentication).
See [RFC4086] for more information about generating randomness. See [RFC4086] for more information about generating randomness.
This document recommends use of SCRAM with SHA-256 hash. SCRAM-SHA-1 This document recommends use of SCRAM with SHA-256 hash. SCRAM-SHA-1
is registered for database compatibility with implementations of RFC is registered for database compatibility with implementations of RFC
5802 (such as IMAP or XMPP servers) which want to also expose HTTP 5802 (such as IMAP or XMPP servers) which want to also expose HTTP
access to a related service, but it is not recommended for new access to a related service, but it is not recommended for new
deployments. deployments.
9. IANA Considerations 9. IANA Considerations
skipping to change at page 16, line 34 skipping to change at page 16, line 35
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>. <http://www.rfc-editor.org/info/rfc2104>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
DOI 10.17487/RFC3454, December 2002,
<http://www.rfc-editor.org/info/rfc3454>.
[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, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, DOI 10.17487/RFC4013, February
2005, <http://www.rfc-editor.org/info/rfc4013>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>. <http://www.rfc-editor.org/info/rfc4648>.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
<http://www.rfc-editor.org/info/rfc5056>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response Authentication Mechanism "Salted Challenge Response Authentication Mechanism
(SCRAM) SASL and GSS-API Mechanisms", RFC 5802, (SCRAM) SASL and GSS-API Mechanisms", RFC 5802,
DOI 10.17487/RFC5802, July 2010, DOI 10.17487/RFC5802, July 2010,
<http://www.rfc-editor.org/info/rfc5802>. <http://www.rfc-editor.org/info/rfc5802>.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, DOI 10.17487/RFC5929, July 2010,
<http://www.rfc-editor.org/info/rfc5929>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, (SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, DOI 10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>. <http://www.rfc-editor.org/info/rfc6234>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235, Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014, DOI 10.17487/RFC7235, June 2014,
<http://www.rfc-editor.org/info/rfc7235>. <http://www.rfc-editor.org/info/rfc7235>.
skipping to change at page 18, line 31 skipping to change at page 18, line 15
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>. <http://www.rfc-editor.org/info/rfc4086>.
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, (LDAP): Technical Specification Road Map", RFC 4510,
DOI 10.17487/RFC4510, June 2006, DOI 10.17487/RFC4510, June 2006,
<http://www.rfc-editor.org/info/rfc4510>. <http://www.rfc-editor.org/info/rfc4510>.
[RFC4616] Zeilenga, K., Ed., "The PLAIN Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4616,
DOI 10.17487/RFC4616, August 2006,
<http://www.rfc-editor.org/info/rfc4616>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>. <http://www.rfc-editor.org/info/rfc4949>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[tls-server-end-point] [RFC6331] Melnikov, A., "Moving DIGEST-MD5 to Historic", RFC 6331,
Zhu, L., , "Registration of TLS server end-point channel DOI 10.17487/RFC6331, July 2011,
bindings", IANA http://www.iana.org/assignments/ <http://www.rfc-editor.org/info/rfc6331>.
channel-binding-types/tls-server-end-point, July 2008.
Author's Address Author's Address
Alexey Melnikov Alexey Melnikov
Isode Ltd Isode Ltd
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
 End of changes. 24 change blocks. 
97 lines changed or deleted 75 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/