[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

   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]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/