diff options
Diffstat (limited to 'doc/protocol/draft-ietf-tls-srp-02.txt')
| -rw-r--r-- | doc/protocol/draft-ietf-tls-srp-02.txt | 730 |
1 files changed, 0 insertions, 730 deletions
diff --git a/doc/protocol/draft-ietf-tls-srp-02.txt b/doc/protocol/draft-ietf-tls-srp-02.txt deleted file mode 100644 index 1a438dc7c3..0000000000 --- a/doc/protocol/draft-ietf-tls-srp-02.txt +++ /dev/null @@ -1,730 +0,0 @@ - - - -Transport Layer Security Working D. Taylor -Group Forge Research Pty Ltd -Internet-Draft August 21, 2002 -Expires: February 19, 2003 - - - Using SRP for TLS Authentication - draft-ietf-tls-srp-02 - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on February 19, 2003. - -Copyright Notice - - Copyright (C) The Internet Society (2002). All Rights Reserved. - -Abstract - - This memo presents a technique for using the SRP [2] (Secure Remote - Password) protocol as an authentication method for the TLS - [1](Transport Layer Security) protocol. - - - - - - - - - - - -Taylor Expires February 19, 2003 [Page 1] - -Internet-Draft Using SRP for TLS Authentication August 2002 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. SRP Authentication in TLS . . . . . . . . . . . . . . . . . 4 - 2.1 Modifications to the TLS Handshake Sequence . . . . . . . . 4 - 2.1.1 Message Sequence . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1.2 Session Re-use . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.2 SRP Verifier Message Digest Selection . . . . . . . . . . . 5 - 2.3 Changes to the Handshake Message Contents . . . . . . . . . 5 - 2.3.1 Client hello . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.3.2 Server hello . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.3.3 Server certificate . . . . . . . . . . . . . . . . . . . . . 5 - 2.3.4 Client key exchange . . . . . . . . . . . . . . . . . . . . 6 - 2.3.5 Server key exchange . . . . . . . . . . . . . . . . . . . . 6 - 2.4 Calculating the Pre-master Secret . . . . . . . . . . . . . 6 - 2.5 Cipher Suite Definitions . . . . . . . . . . . . . . . . . . 6 - 2.6 New Message Structures . . . . . . . . . . . . . . . . . . . 7 - 2.6.1 ExtensionType . . . . . . . . . . . . . . . . . . . . . . . 7 - 2.6.2 Client Hello . . . . . . . . . . . . . . . . . . . . . . . . 7 - 2.6.3 Server Hello . . . . . . . . . . . . . . . . . . . . . . . . 8 - 2.6.4 Client Key Exchange . . . . . . . . . . . . . . . . . . . . 8 - 2.6.5 Server Key Exchange . . . . . . . . . . . . . . . . . . . . 8 - 3. Security Considerations . . . . . . . . . . . . . . . . . . 10 - References . . . . . . . . . . . . . . . . . . . . . . . . . 11 - Author's Address . . . . . . . . . . . . . . . . . . . . . . 11 - A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 - Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 - - - - - - - - - - - - - - - - - - - - - - - - -Taylor Expires February 19, 2003 [Page 2] - -Internet-Draft Using SRP for TLS Authentication August 2002 - - -1. Introduction - - At the time of writing, TLS uses public key certificiates with RSA/ - DSA digital signatures, or Kerberos, for authentication. - - These authentication methods do not seem well suited to the - applications now being adapted to use TLS (IMAP [3], FTP [5], or - TELNET [6], for example). Given these protocols (and others like - them) are designed to use the user name and password method of - authentication, being able to safely use user names and passwords to - authenticate the TLS connection provides a much easier route to - additional security than implementing a public key infrastructure in - certain situations. - - SRP 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 - authetication 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. - - - - - - - - - - - - - - - - - - - - - - - - - - -Taylor Expires February 19, 2003 [Page 3] - -Internet-Draft Using SRP for TLS Authentication August 2002 - - -2. SRP Authentication in TLS - -2.1 Modifications to the TLS Handshake Sequence - - The SRP protocol can not be implemented using the sequence of - handshake messages defined in [1] due to the sequence in which the - SRP messages must be sent. - - This document presents a new sequence of handshake messages for - handshakes using the SRP authentication method. - -2.1.1 Message Sequence - - Handshake Message Flow for SRP Authentication - - Client Server - | | - Client Hello (U) ------------------------> | - | <---------------------------- Server Hello (g, N, s) - | <---------------------------- Certificate* - Client Key Exchange (A) -----------------> | - | <---------------------------- Server Key Exchange (B) - | <---------------------------- Server Hello Done - change cipher spec | - Finished --------------------------------> | - | change cipher spec - | <---------------------------- Finished - | | - - * Indicates optional or situation-dependent messages that are not - always sent. - - The identifiers given after each message name refer to the SRP - variables included in that message. The variables U, g, N, s, A, and - B are defined in [2]. - - Extended client and server hello messages, as defined in [7], are - used to to send the initial client and server values. - - The client key exchange message is sent during the sequence of server - messages. This modification is required because the client must send - its public key (A) before it receives the servers public key (B), as - stated in Section 3 of [2]. - -2.1.2 Session Re-use - - The short handshake mechanism for re-using sessions for new - connections, and renegotiating keys for existing connections will - - - -Taylor Expires February 19, 2003 [Page 4] - -Internet-Draft Using SRP for TLS Authentication August 2002 - - - still work with the SRP authentication mechanism and handshake. - - When a client attemps to re-use a session that uses SRP - authentication, it MUST still include the SRP extension carrying the - user name (U) in the client hello message, in case the server cannot - or will not allow re-use of the session, meaning a full handshake - sequence is required. - - If a client requests an existing session and the server agrees to use - it (meaning the short handshake will be used), the server MAY omit - the SRP extension from the server hello message, as the information - it contains is not used in the short handshake. - -2.2 SRP Verifier Message Digest Selection - - The cipher suites defined in this document use the SHA-1 message - digest with the SRP algorithm, as specified in [2]. Implementations - conforming to this document MUST use the SHA-1 message digest. - - Future documents may define other cipher suites that use different - message digests, or other similar functions, with the SRP algorithm. - -2.3 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.6. - -2.3.1 Client hello - - The user name is appended to the standard client hello message using - the hello message extension mechanism defined in [7]. - -2.3.2 Server hello - - The the generator (g), the prime (N), and the salt value (s) read - from the SRP password file are appended to the server hello message - using the hello message extension mechanism defined in [7]. - -2.3.3 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.5 for details of - which ciphersuites defined in this document require a server - certificate to be sent. - - - - -Taylor Expires February 19, 2003 [Page 5] - -Internet-Draft Using SRP for TLS Authentication August 2002 - - - Because the server's certificate is only used for generating a - digital signature in SRP cipher suites, the certificate sent MUST - contain a public key that can be used for generating digital - signatures. - -2.3.4 Client key exchange - - The client key exchange message carries the client's public key (A), - which is calculated using both information known locally, and - information received in the server hello message. This message MUST - be sent before the server key exchange message. - -2.3.5 Server key exchange - - The server key exchange message contains the server's public key (B). - The server key exchange message MUST be sent after the client key - exchange message. - - If the server has sent a certificate message, the server key exchange - message MUST be signed. - -2.4 Calculating the Pre-master Secret - - The shared secret resulting from the SRP calculations (S) (defined in - [2]) is used as the pre-master secret. - - The finished messages perform the same function as the client and - server evidence messages specified in [2]. If either the client or - the server calculate an incorrect value, the finished messages will - not be understood, and the connection will be dropped as specified in - [1]. - -2.5 Cipher Suite Definitions - - The following cipher suites are added by this draft. The usage of - AES ciphersuites is as defined in [4]. - - CipherSuite TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x50 }; - - CipherSuite TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x51 }; - - CipherSuite TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x52 }; - - CipherSuite TLS_SRP_SHA_WITH_AES_128_CBC_SHA = { 0x00,0x53 }; - - CipherSuite TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x54 }; - - CipherSuite TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x55 }; - - - -Taylor Expires February 19, 2003 [Page 6] - -Internet-Draft Using SRP for TLS Authentication August 2002 - - - CipherSuite TLS_SRP_SHA_WITH_AES_256_CBC_SHA = { 0x00,0x56 }; - - CipherSuite TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x57 }; - - CipherSuite TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x58 }; - - Cipher suites that do not include a digitial signature algorithm - identifier assume the server is authenticated by its possesion of the - SRP database. - - 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. - - Implementations conforming to this specification MUST implement the - TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA ciphersuite, SHOULD implement the - TLS_SRP_SHA_WITH_AES_128_CBC_SHA and TLS_SRP_SHA_WITH_AES_256_CBC_SHA - ciphersuites, and MAY implement the remaining ciphersuites. - -2.6 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 [1]. - - When encoding the numbers g, N, A, and B as opaque types, if the most - significant bit is set, an extra byte of value 0x00 (all bits - cleared) MUST be added as the most significant byte. This is done as - a safeguard against implementations that do not assume these numbers - are positive. - -2.6.1 ExtensionType - - A new value, "srp(6)", has been added to the enumerated - ExtensionType, defined in [7]. This value is used as the extension - number for the extensions in both the client hello message and the - server hello message. - -2.6.2 Client Hello - - The user name (U) is encoded in an SRPExtension structure, and sent - in an extended client hello message, using an extension of type - "srp". - - - - - - - -Taylor Expires February 19, 2003 [Page 7] - -Internet-Draft Using SRP for TLS Authentication August 2002 - - - enum { client, server } ClientOrServerExtension; - - struct { - select(ClientOrServerExtension) { - case client: - opaque srp_U<1..2^8-1>; - case server: - opaque srp_s<1..2^8-1> - opaque srp_N<1..2^16-1>; - opaque srp_g<1..2^16-1>; - } - } SRPExtension; - - -2.6.3 Server Hello - - The generator (g), the prime (N), and the salt value (s) are encoded - in an SRPExtension structure, which is sent in an extended server - hello message, using an extension of type "srp". - -2.6.4 Client Key Exchange - - When the value of KeyExchangeAlgorithm is set to "srp", the client's - ephemeral public key (A) is sent in the client key exchange message, - encoded in an ClientSRPPublic structure. - - An extra value, srp, has been added to the enumerated - KeyExchangeAlgorithm, originally defined in TLS [1]. - - struct { - select (KeyExchangeAlgorithm) { - case rsa: EncryptedPreMasterSecret; - case diffie_hellman: ClientDiffieHellmanPublic; - case srp: ClientSRPPublic; /* new entry */ - } exchange_keys; - } ClientKeyExchange; - - enum { rsa, diffie_hellman, srp } KeyExchangeAlgorithm; - - struct { - opaque srp_A<1..2^16-1>; - } ClientSRPPublic; - - -2.6.5 Server Key Exchange - - When the value of KeyExchangeAlgorithm is set to "srp", the server's - ephemeral public key (B) is sent in the server key exchange message, - - - -Taylor Expires February 19, 2003 [Page 8] - -Internet-Draft Using SRP for TLS Authentication August 2002 - - - encoded in an ServerSRPPublic structure. - - The following table gives the SignatureAlgorithm value to be used for - each ciphersuite. - - Ciphersuite SignatureAlgorithm - - TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA anonymous - - TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA rsa - - TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA dsa - - TLS_SRP_SHA_WITH_AES_128_CBC_SHA anonymous - - TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA rsa - - TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA dsa - - TLS_SRP_SHA_WITH_AES_256_CBC_SHA anonymous - - TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA rsa - - TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA dsa - - - struct { - select (KeyExchangeAlgorithm) { - case diffie_hellman: - ServerDHParams params; - Signature signed_params; - case rsa: - ServerRSAParams params; - Signature signed_params; - case srp: /* new entry */ - ServerSRPPublic params; - Signature signed_params; - }; - } ServerKeyExchange; - - struct { - opaque srp_B<1..2^16-1>; - } ServerSRPPublic; /* SRP parameters */ - - - - - - - - -Taylor Expires February 19, 2003 [Page 9] - -Internet-Draft Using SRP for TLS Authentication August 2002 - - -3. Security Considerations - - If an attacker is able to steal the SRP verifier file, the attacker - can masquerade as the real host. Filesystem based X.509 certificate - installations are vulnerable to a similar attack unless the server's - certificate is issued from a PKI that maintains revocation lists, and - the client TLS code can both contact the PKI and make use of the - revocation list. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Taylor Expires February 19, 2003 [Page 10] - -Internet-Draft Using SRP for TLS Authentication August 2002 - - -References - - [1] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January - 1999. - - [2] Wu, T., "The SRP Authentication and Key Exchange System", RFC - 2945, September 2000. - - [3] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June - 1999. - - [4] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for - Transport Layer Security (TLS)", RFC 3268, June 2002. - - [5] Ford-Hutchinson, P., Carpenter, M., Hudson, T., Murray, E. and - V. Wiegand, "Securing FTP with TLS", draft-murray-auth-ftp-ssl- - 09 (work in progress), April 2002. - - [6] Boe, M. and J. Altman, "TLS-based Telnet Security", draft-ietf- - tn3270e-telnet-tls-06 (work in progress), April 2002. - - [7] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T. - Wright, "TLS Extensions", draft-ietf-tls-extensions-05 (work in - progress), July 2002. - - -Author's Address - - David Taylor - Forge Research Pty Ltd - - EMail: DavidTaylor@forge.com.au - URI: http://www.forge.com.au/ - - - - - - - - - - - - - - - - - - -Taylor Expires February 19, 2003 [Page 11] - -Internet-Draft Using SRP for TLS Authentication August 2002 - - -Appendix A. Acknowledgements - - Thanks to all on the IETF tls mailing list for ideas and analysis. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Taylor Expires February 19, 2003 [Page 12] - -Internet-Draft Using SRP for TLS Authentication August 2002 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2002). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Taylor Expires February 19, 2003 [Page 13] - - |