Network Working Group D. Taylor
Request for Comments: 5054 Independent
Category: Informational T. Wu
Cisco
N. Mavrogiannopoulos
T. Perrin
Independent
November 2007
Using the Secure Remote Password (SRP) Protocol for TLS Authentication
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract
This memo presents a technique for using the Secure Remote Password
protocol as an authentication method for the Transport Layer Security
protocol.
Taylor, et al. Informational [Page 1]
RFC 5054 Using SRP for TLS Authentication November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SRP Authentication in TLS . . . . . . . . . . . . . . . . . . 3
2.1. Notation and Terminology . . . . . . . . . . . . . . . . . 3
2.2. Handshake Protocol Overview . . . . . . . . . . . . . . . 4
2.3. Text Preparation . . . . . . . . . . . . . . . . . . . . . 5
2.4. SRP Verifier Creation . . . . . . . . . . . . . . . . . . 5
2.5. Changes to the Handshake Message Contents . . . . . . . . 5
2.5.1. Client Hello . . . . . . . . . . . . . . . . . . . . . 6
2.5.2. Server Certificate . . . . . . . . . . . . . . . . . . 7
2.5.3. Server Key Exchange . . . . . . . . . . . . . . . . . 7
2.5.4. Client Key Exchange . . . . . . . . . . . . . . . . . 8
2.6. Calculating the Premaster Secret . . . . . . . . . . . . . 8
2.7. Ciphersuite Definitions . . . . . . . . . . . . . . . . . 9
2.8. New Message Structures . . . . . . . . . . . . . . . . . . 9
2.8.1. Client Hello . . . . . . . . . . . . . . . . . . . . . 10
2.8.2. Server Key Exchange . . . . . . . . . . . . . . . . . 10
2.8.3. Client Key Exchange . . . . . . . . . . . . . . . . . 11
2.9. Error Alerts . . . . . . . . . . . . . . . . . . . . . . . 11
3. Security Considerations . . . . . . . . . . . . . . . . . . . 12
3.1. General Considerations for Implementors . . . . . . . . . 12
3.2. Accepting Group Parameters . . . . . . . . . . . . . . . . 12
3.3. Protocol Characteristics . . . . . . . . . . . . . . . . . 12
3.4. Hash Function Considerations . . . . . . . . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Normative References . . . . . . . . . . . . . . . . . . . 14
5.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. SRP Group Parameters . . . . . . . . . . . . . . . . 16
Appendix B. SRP Test Vectors . . . . . . . . . . . . . . . . . . 21
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 22
Taylor, et al. Informational [Page 2]
RFC 5054 Using SRP for TLS Authentication November 2007
1. Introduction
At the time of writing TLS [TLS] uses public key certificates, pre-
shared keys, or Kerberos for authentication.
These authentication methods do not seem well suited to certain
applications now being adapted to use TLS ([IMAP], for example).
Given that many protocols are designed to use the user name and
password method of authentication, being able to safely use user
names and passwords provides an easier route to additional security.
SRP ([SRP], [SRP-6]) is an authentication method that allows the use
of user names and passwords over unencrypted channels without
revealing the password to an eavesdropper. SRP also supplies a
shared secret at the end of the authentication sequence that can be
used to generate encryption keys.
This document describes the use of the SRP authentication method for
TLS.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [REQ].
2. SRP Authentication in TLS
2.1. Notation and Terminology
The version of SRP used here is sometimes referred to as "SRP-6"
[SRP-6]. This version is a slight improvement over "SRP-3", which
was described in [SRP] and [SRP-RFC]. For convenience, this document
and [SRP-RFC] include the details necessary to implement SRP-6;
[SRP-6] is cited for informative purposes only.
Taylor, et al. Informational [Page 3]
RFC 5054 Using SRP for TLS Authentication November 2007
This document uses the variable names defined in [SRP-6]:
N, g: group parameters (prime and generator)
s: salt
B, b: server's public and private values
A, a: client's public and private values
I: user name (aka "identity")
P: password
v: verifier
k: SRP-6 multiplier
The | symbol indicates string concatenation, the ^ operator is the
exponentiation operation, and the % operator is the integer remainder
operation.
Conversion between integers and byte-strings assumes the most
significant bytes are stored first, as per [TLS] and [SRP-RFC]. In
the following text, if a conversion from integer to byte-string is
implicit, the most significant byte in the resultant byte-string MUST
be non-zero. If a conversion is explicitly specified with the
operator PAD(), the integer will first be implicitly converted, then
the resultant byte-string will be left-padded with zeros (if
necessary) until its length equals the implicitly-converted length of
N.
2.2. Handshake Protocol Overview
The advent of [SRP-6] allows the SRP protocol to be implemented using
the standard sequence of handshake messages defined in [TLS].
The parameters to various messages are given in the following
diagram.
Taylor, et al. Informational [Page 4]
RFC 5054 Using SRP for TLS Authentication November 2007
Client Server
Client Hello (I) -------->
Server Hello
Certificate*
Server Key Exchange (N, g, s, B)
<-------- Server Hello Done
Client Key Exchange (A) -------->
[Change cipher spec]
Finished -------->
[Change cipher spec]
<-------- Finished
Application Data <-------> Application Data
* Indicates an optional message that is not always sent.
Figure 1
2.3. Text Preparation
The user name and password strings SHALL be UTF-8 encoded Unicode,
prepared using the [SASLPREP] profile of [STRINGPREP].
2.4. SRP Verifier Creation
The verifier is calculated as described in Section 3 of [SRP-RFC].
We give the algorithm here for convenience.
The verifier (v) is computed based on the salt (s), user name (I),
password (P), and group parameters (N, g). The computation uses the
[SHA1] hash algorithm:
x = SHA1(s | SHA1(I | ":" | P))
v = g^x % N
2.5. Changes to the Handshake Message Contents
This section describes the changes to the TLS handshake message
contents when SRP is being used for authentication. The definitions
of the new message contents and the on-the-wire changes are given in
Section 2.8.
Taylor, et al. Informational [Page 5]
RFC 5054 Using SRP for TLS Authentication November 2007
2.5.1. Client Hello
The user name is appended to the standard client hello message using
the extension mechanism defined in [TLSEXT] (see Section 2.8.1).
This user name extension is henceforth called the "SRP extension".
The following subsections give details of its use.
2.5.1.1. Session Resumption
When a client attempts to resume a session that uses SRP
authentication, the client MUST include the SRP extension in the
client hello message, in case the server cannot or will not allow
session resumption, meaning a full handshake is required.
If the server does agree to resume an existing session, the server
MUST ignore the information in the SRP extension of the client hello
message, except for its inclusion in the finished message hashes.
This is to ensure that attackers cannot replace the authenticated
identity without supplying the proper authentication information.
2.5.1.2. Missing SRP Extension
The client may offer SRP cipher suites in the hello message but omit
the SRP extension. If the server would like to select an SRP cipher
suite in this case, the server SHOULD return a fatal
"unknown_psk_identity" alert (see Section 2.9) immediately after
processing the client hello message.
A client receiving this alert MAY choose to reconnect and resend the
hello message, this time with the SRP extension. This allows the
client to advertise that it supports SRP, but not have to prompt the
user for his user name and password, nor expose the user name in the
clear, unless necessary.
2.5.1.3. Unknown SRP User Name
If the server doesn't have a verifier for the user name in the SRP
extension, the server MAY abort the handshake with an
"unknown_psk_identity" alert (see Section 2.9). Alternatively, if
the server wishes to hide the fact that this user name doesn't have a
verifier, the server MAY simulate the protocol as if a verifier
existed, but then reject the client's finished message with a
"bad_record_mac" alert, as if the password was incorrect.
To simulate the existence of an entry for each user name, the server
must consistently return the same salt (s) and group (N, g) values
for the same user name. For example, the server could store a secret
"seed key" and then use HMAC-SHA1(seed_key, "salt" | user_name) to
Taylor, et al. Informational [Page 6]
RFC 5054 Using SRP for TLS Authentication November 2007
generate the salts [HMAC]. For B, the server can return a random
value between 1 and N-1 inclusive. However, the server should take
care to simulate computation delays. One way to do this is to
generate a fake verifier using the "seed key" approach, and then
proceed with the protocol as usual.
2.5.2. Server Certificate
The server MUST send a certificate if it agrees to an SRP cipher
suite that requires the server to provide additional authentication
in the form of a digital signature. See Section 2.7 for details of
which cipher suites defined in this document require a server
certificate to be sent.
2.5.3. Server Key Exchange
The server key exchange message contains the prime (N), the generator
(g), and the salt value (s) read from the SRP password file based on
the user name (I) received in the client hello extension.
The server key exchange message also contains the server's public
value (B). The server calculates this value as B = k*v + g^b % N,
where b is a random number that SHOULD be at least 256 bits in length
and k = SHA1(N | PAD(g)).
If the server has sent a certificate message, the server key exchange
message MUST be signed.
The group parameters (N, g) sent in this message MUST have N as a
safe prime (a prime of the form N=2q+1, where q is also prime). The
integers from 1 to N-1 will form a group under multiplication % N,
and g MUST be a generator of this group. In addition, the group
parameters MUST NOT be specially chosen to allow efficient
computation of discrete logarithms.
The SRP group parameters in Appendix A satisfy the above
requirements, so the client SHOULD accept any parameters from this
appendix that have large enough N values to meet her security
requirements.
The client MAY accept other group parameters from the server, if the
client has reason to believe that these parameters satisfy the above
requirements, and the parameters have large enough N values. For
example, if the parameters transmitted by the server match parameters
on a "known-good" list, the client may choose to accept them. See
Section 3 for additional security considerations relevant to the
acceptance of the group parameters.
Taylor, et al. Informational [Page 7]
RFC 5054 Using SRP for TLS Authentication November 2007
Group parameters that are not accepted via one of the above methods
MUST be rejected with an "insufficient_security" alert (see
Section 2.9).
The client MUST abort the handshake with an "illegal_parameter" alert
if B % N = 0.
2.5.4. Client Key Exchange
The client key exchange message carries the client's public value
(A). The client calculates this value as A = g^a % N, where a is a
random number that SHOULD be at least 256 bits in length.
The server MUST abort the handshake with an "illegal_parameter" alert
if A % N = 0.
2.6. Calculating the Premaster Secret
The premaster secret is calculated by the client as follows:
I, P =
N, g, s, B =
a = random()
A = g^a % N
u = SHA1(PAD(A) | PAD(B))
k = SHA1(N | PAD(g))
x = SHA1(s | SHA1(I | ":" | P))
= (B - (k * g^x)) ^ (a + (u * x)) % N
The premaster secret is calculated by the server as follows:
N, g, s, v =
b = random()
k = SHA1(N | PAD(g))
B = k*v + g^b % N
A =
u = SHA1(PAD(A) | PAD(B))
= (A * v^u) ^ b % N
The finished messages perform the same function as the client and
server evidence messages (M1 and M2) specified in [SRP-RFC]. If
either the client or the server calculates an incorrect premaster
secret, the finished messages will fail to decrypt properly, and the
other party will return a "bad_record_mac" alert.
If a client application receives a "bad_record_mac" alert when
performing an SRP handshake, it should inform the user that the
entered user name and password are incorrect.
Taylor, et al. Informational [Page 8]
RFC 5054 Using SRP for TLS Authentication November 2007
2.7. Ciphersuite Definitions
The following cipher suites are added by this document. The usage of
Advanced Encryption Standard (AES) cipher suites is as defined in
[AESCIPH].
CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1A };
CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1B };
CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1C };
CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0xC0,0x1D };
CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0xC0,0x1E };
CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0xC0,0x1F };
CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0xC0,0x20 };
CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0xC0,0x21 };
CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0xC0,0x22 };
Cipher suites that begin with TLS_SRP_SHA_RSA or TLS_SRP_SHA_DSS
require the server to send a certificate message containing a
certificate with the specified type of public key, and to sign the
server key exchange message using a matching private key.
Cipher suites that do not include a digital signature algorithm
identifier assume that the server is authenticated by its possession
of the SRP verifier.
Implementations conforming to this specification MUST implement the
TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA cipher suite, SHOULD implement the
TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA
cipher suites, and MAY implement the remaining cipher suites.
2.8. New Message Structures
This section shows the structure of the messages passed during a
handshake that uses SRP for authentication. The representation
language used is the same as that used in [TLS].
Taylor, et al. Informational [Page 9]
RFC 5054 Using SRP for TLS Authentication November 2007
2.8.1. Client Hello
A new extension "srp", with value 12, has been added to the
enumerated ExtensionType defined in [TLSEXT]. This value MUST be
used as the extension number for the SRP extension.
The "extension_data" field of the SRP extension SHALL contain:
opaque srp_I<1..2^8-1>;
where srp_I is the user name, encoded per Section 2.3.
2.8.2. Server Key Exchange
A new value, "srp", has been added to the enumerated
KeyExchangeAlgorithm originally defined in [TLS].
When the value of KeyExchangeAlgorithm is set to "srp", the server's
SRP parameters are sent in the server key exchange message, encoded
in a ServerSRPParams structure.
If a certificate is sent to the client, the server key exchange
message must be signed.
enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
case srp: /* new entry */
ServerSRPParams params;
Signature signed_params;
};
} ServerKeyExchange;
struct {
opaque srp_N<1..2^16-1>;
opaque srp_g<1..2^16-1>;
opaque srp_s<1..2^8-1>;
opaque srp_B<1..2^16-1>;
} ServerSRPParams; /* SRP parameters */
Taylor, et al. Informational [Page 10]
RFC 5054 Using SRP for TLS Authentication November 2007
2.8.3. Client Key Exchange
When the value of KeyExchangeAlgorithm is set to "srp", the client's
public value (A) is sent in the client key exchange message, encoded
in a ClientSRPPublic structure.
struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
case srp: ClientSRPPublic; /* new entry */
} exchange_keys;
} ClientKeyExchange;
struct {
opaque srp_A<1..2^16-1>;
} ClientSRPPublic;
2.9. Error Alerts
This document introduces four new uses of alerts:
o "unknown_psk_identity" (115) - this alert MAY be sent by a server
that would like to select an offered SRP cipher suite, if the SRP
extension is absent from the client's hello message. This alert
is always fatal. See Section 2.5.1.2 for details.
o "unknown_psk_identity" (115) - this alert MAY be sent by a server
that receives an unknown user name. This alert is always fatal.
See Section 2.5.1.3 for details.
o "insufficient_security" (71) - this alert MUST be sent by a client
that receives unknown or untrusted (N, g) values. This alert is
always fatal. See Section 2.5.3 for details.
o "illegal_parameter" (47) - this alert MUST be sent by a client or
server that receives a key exchange message with A % N = 0 or B %
N = 0. This alert is always fatal. See Section 2.5.3 and
Section 2.5.4 and for details.
The "insufficient_security" and "illegal_parameter" alerts are
defined in [TLS]. The "unknown_psk_identity" alert is defined in
[PSK].
Taylor, et al. Informational [Page 11]
RFC 5054 Using SRP for TLS Authentication November 2007
3. Security Considerations
3.1. General Considerations for Implementors
The checks described in Section 2.5.3 and Section 2.5.4 on the
received values for A and B are CRUCIAL for security and MUST be
performed.
The private values a and b SHOULD be at least 256-bit random numbers,
to give approximately 128 bits of security against certain methods of
calculating discrete logarithms. See [TLS], Section D.1, for advice
on choosing cryptographically secure random numbers.
3.2. Accepting Group Parameters
An attacker who could calculate discrete logarithms % N could
compromise user passwords, and could also compromise the
confidentiality and integrity of TLS sessions. Clients MUST ensure
that the received parameter N is large enough to make calculating
discrete logarithms computationally infeasible.
An attacker may try to send a prime value N that is large enough to
be secure, but that has a special form for which the attacker can
more easily compute discrete logarithms (e.g., using the algorithm
discussed in [TRAPDOOR]). If the client executes the protocol using
such a prime, the client's password could be compromised. Because of
the difficulty of checking for such primes in real time, clients
SHOULD only accept group parameters that come from a trusted source,
such as those listed in Appendix A, or parameters configured locally
by a trusted administrator.
3.3. Protocol Characteristics
If an attacker learns a user's SRP verifier (e.g., by gaining access
to a server's password file), the attacker can masquerade as the real
server to that user, and can also attempt a dictionary attack to
recover that user's password.
An attacker could repeatedly contact an SRP server and try to guess a
legitimate user's password. Servers SHOULD take steps to prevent
this, such as limiting the rate of authentication attempts from a
particular IP address or against a particular user name.
The client's user name is sent in the clear in the Client Hello
message. To avoid sending the user name in the clear, the client
could first open a conventional anonymous or server-authenticated
connection, then renegotiate an SRP-authenticated connection with the
handshake protected by the first connection.
Taylor, et al. Informational [Page 12]
RFC 5054 Using SRP for TLS Authentication November 2007
If the client receives an "unknown_psk_identity" alert in response to
a client hello, this alert may have been inserted by an attacker.
The client should be careful about making any decisions, or forming
any conclusions, based on receiving this alert.
It is possible to choose a (user name, password) pair such that the
resulting verifier will also match other, related, (user name,
password) pairs. Thus, anyone using verifiers should be careful not
to assume that only a single (user name, password) pair matches the
verifier.
3.4. Hash Function Considerations
This protocol uses SHA-1 to derive several values:
o u prevents an attacker who learns a user's verifier from being
able to authenticate as that user (see [SRP-6]).
o k prevents an attacker who can select group parameters from being
able to launch a 2-for-1 guessing attack (see [SRP-6]).
o x contains the user's password mixed with a salt.
Cryptanalytic attacks against SHA-1 that only affect its collision-
resistance do not compromise these uses. If attacks against SHA-1
are discovered that do compromise these uses, new cipher suites
should be specified to use a different hash algorithm.
In this situation, clients could send a Client Hello message
containing new and/or old SRP cipher suites along with a single SRP
extension. The server could then select the appropriate cipher suite
based on the type of verifier it has stored for this user.
4. IANA Considerations
This document defines a new TLS extension "srp" (value 12), whose
value has been assigned from the TLS ExtensionType Registry defined
in [TLSEXT].
This document defines nine new cipher suites, whose values have been
assigned from the TLS Ciphersuite registry defined in [TLS].
CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1A };
CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1B };
CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0xC0,0x1C };
Taylor, et al. Informational [Page 13]
RFC 5054 Using SRP for TLS Authentication November 2007
CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0xC0,0x1D };
CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0xC0,0x1E };
CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0xC0,0x1F };
CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0xC0,0x20 };
CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0xC0,0x21 };
CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0xC0,0x22 };
5. References
5.1. Normative References
[REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[TLS] Dierks, T. and E. Rescorla, "The TLS Protocol version
1.1", RFC 4346, April 2006.
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
J., and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[SASLPREP] Zeilenga, K., "SASLprep: Stringprep profile for user
names and passwords", RFC 4013, February 2005.
[SRP-RFC] Wu, T., "The SRP Authentication and Key Exchange
System", RFC 2945, September 2000.
[SHA1] "Secure Hash Standard (SHS)", FIPS 180-2, August 2002.
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[AESCIPH] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)",
RFC 3268, June 2002.
Taylor, et al. Informational [Page 14]
RFC 5054 Using SRP for TLS Authentication November 2007
[PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, December 2005.
[MODP] Kivinen, T. and M. Kojo, "More Modular Exponentiation
(MODP) Diffie-Hellman groups for Internet Key Exchange
(IKE)", RFC 3526, May 2003.
5.2. Informative References
[IMAP] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, June 1999.
[SRP-6] Wu, T., "SRP-6: Improvements and Refinements to the
Secure Remote Password Protocol", Submission to IEEE
P1363.2 working group, October 2002,
=
B0DC82BA BCF30674 AE450C02 87745E79 90A3381F 63B387AA F271A10D
233861E3 59B48220 F7C4693C 9AE12B0A 6F67809F 0876E2D0 13800D6C
41BB59B6 D5979B5C 00A172B4 A2A5903A 0BDCAF8A 709585EB 2AFAFA8F
3499B200 210DCC1F 10EB3394 3CD67FC8 8A2F39A4 BE5BEC4E C0A3212D
C346D7E4 74B29EDE 8A469FFE CA686E5A
Appendix C. Acknowledgements
Thanks to all on the IETF TLS mailing list for ideas and analysis.
Taylor, et al. Informational [Page 22]
RFC 5054 Using SRP for TLS Authentication November 2007
Authors' Addresses
David Taylor
Independent
EMail: dtaylor@gnutls.org
Tom Wu
Cisco
EMail: thomwu@cisco.com
Nikos Mavrogiannopoulos
Independent
EMail: nmav@gnutls.org
URI: http://www.gnutls.org/
Trevor Perrin
Independent
EMail: trevp@trevp.net
URI: http://trevp.net/
Taylor, et al. Informational [Page 23]
RFC 5054 Using SRP for TLS Authentication November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Taylor, et al. Informational [Page 24]
RFC, FYI, BCP