Transport Layer Security Working Group J.Banes Internet Draft C.Crall Document: draft-ietf-tls-emailaddr-00.txt Microsoft Expires: March 2004 September 2003 Update to Transport Layer Security (TLS) Extensions Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [i]. 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document is an update to the Transport Layer Security (TLS) Extensions. This update provides an additional choice in the ServerName type of the Server_Name extension. The Server Name extension allows the client to specify the name of the server to which it is attempting to connect. The new choice specified in this document allows the client to specify an email name as the server name. Conventions used in this document 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 [KEYWORDS][KEYWORDS]. Table of Contents Crall Expires û March 2004 [Page 1] draft-ietf-tls-emailaddr-00.txt September 2003 1. Introduction...................................................1 2. EmailAddr ServerName Indication................................1 3. Error Alerts...................................................1 4. Security Considerations........................................1 5. Acknowledgments................................................1 6. AuthorsÆ Addresses.............................................1 7. Normative References...........................................1 1. Introduction RFC 3546 [TLSEXT]provides a set of extensions to the Transport Layer Security (TLS) protocol. One of these extensions is the Server Name extension. The Server Name extension provides a mechanism for the client to specify the name of the server to which it is connecting. This extension is provided as part of the client hello message. RFC 3546 defines one Server Name type, ôhostnameö. This draft adds a second Server Name type, ôemailaddrö. 2. EmailAddr ServerName Indication RFC 3546 defines a Server Name Indication as a mechanism for a client to tell a server the name of the server that it is contacting. The Server Name Indication information is helpful when a single server may be acting as multiple virtual servers. RFC 3546 defines the structure shown below which is part of the extended client hello message. struct { NameType name_type; select (name_type) { case host_name: HostName; } name; } ServerName; enum { host_name(0), (255) } NameType; opaque HostName<1..2^16-1>; struct { ServerName server_name_list<1..2^16-1> } ServerNameList; Crall Expires û March 2004 [Page 2] draft-ietf-tls-emailaddr-00.txt September 2003 This draft proposes a new NameType be added, ôemail_addrö. As with host_name, email_addr is used to identify the appropriate virtual server and therefore help the server select the appropriate certificate to return to the client. Therefore, the new structure looks like the following: struct { NameType name_type; select (name_type) { case host_name: HostName; case email_name: EmailName; } name; } ServerName; enum { host_name(0), email_name(1),(255) } NameType; opaque HostName<1..2^16-1>; opaque EmailName<1..2^16-1>; struct { ServerName server_name_list<1..2^16-1> } ServerNameList; The syntax of EmailName MUST conform to email addresses as defined in RFC 822 [RFC822]. 3. Error Alerts The new alert, ôunrecognized_nameö defined in RFC 3546 should be returned by the server when the server name is unrecognized, whether the name is a HostName or an EmailName. As stated in RFC 3546, this error may be fatal. 4. Security Considerations The security considerations for the new EmailName are similar to those of the HostName in RFC 3546. The server receiving an extended client hello message with an EmailName MUST ensure the name does not cause a buffer overflow within the server. The EmailName supports internationalized hostnames. However, this specification does not deal with security issues of internationalized names. Crall Expires û March 2004 [Page 3] draft-ietf-tls-emailaddr-00.txt September 2003 5. Acknowledgments The authors wish to thank the authors of RFC 3546 for their help. 6. AuthorsÆ Addresses John Banes Microsoft Email: jbanes@microsoft.com Chris Crall Microsoft Email: ccrall@microsoft.com 7. Normative References [KEYWORDS] Bradner, S., ôKey words for use in RFCs to Indicate Requirement Levelsö, BCP 14, RFC 2119, March 1997 [RFC822] Crocker, D., ôStandard for the Format of ARPA Internet Text Messagesö, RFC 822, August 1982 [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwwod, D., Mikkelsen, J. and Wright, T., ôTransport Layer Security (TLS) Extensionsö, RFC 3546, June 2003 Crall Expires û March 2004 [Page 4]