doc/protocol/draft-ietf-tls-emailaddr-00.txt

   1
   2
   3    Transport Layer Security Working Group                       J.Banes
   4    Internet Draft                                               C.Crall
   5    Document: draft-ietf-tls-emailaddr-00.txt                  Microsoft
   6    Expires: March 2004                                   September 2003
   7
   8
   9             Update to Transport Layer Security (TLS) Extensions
  10
  11
  12 Status of this Memo
  13
  14    This document is an Internet-Draft and is in full conformance with
  15    all provisions of Section 10 of RFC2026 [i].
  16
  17    Internet-Drafts are draft documents valid for a maximum of six months
  18    and may be updated, replaced, or obsoleted by other documents at any
  19    time.  It is inappropriate to use Internet-Drafts as reference
  20    material or to cite them other than as "work in progress."
  21
  22    The list of current Internet-Drafts can be accessed at
  23         http://www.ietf.org/ietf/1id-abstracts.txt
  24    The list of Internet-Draft Shadow Directories can be accessed at
  25         http://www.ietf.org/shadow.html.
  26
  27 Copyright Notice
  28
  29    Copyright (C) The Internet Society (2003). All Rights Reserved.
  30
  31
  32 Abstract
  33
  34    This document is an update to the Transport Layer Security (TLS)
  35    Extensions.  This update provides an additional choice in the
  36    ServerName type of the Server_Name extension.  The Server Name
  37    extension allows the client to specify the name of the server to
  38    which it is attempting to connect.  The new choice specified in this
  39    document allows the client to specify an email name as the server
  40    name.
  41
  42
  43 Conventions used in this document
  44
  45    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  46    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
  47    document are to be interpreted as described in RFC-2119
  48    [KEYWORDS][KEYWORDS].
  49
  50 Table of Contents
  51
  52
  53
  54 Crall                    Expires û March 2004                 [Page 1]
  55 \f                   draft-ietf-tls-emailaddr-00.txt     September 2003
  56
  57
  58    1. Introduction...................................................1
  59    2. EmailAddr ServerName Indication................................1
  60    3. Error Alerts...................................................1
  61    4. Security Considerations........................................1
  62    5. Acknowledgments................................................1
  63    6. AuthorsÆ Addresses.............................................1
  64    7. Normative References...........................................1
  65
  66
  67 1.   Introduction
  68
  69    RFC 3546 [TLSEXT]provides a set of extensions to the Transport Layer
  70    Security (TLS) protocol. One of these extensions is the Server Name
  71    extension.  The Server Name extension provides a mechanism for the
  72    client to specify the name of the server to which it is connecting.
  73    This extension is provided as part of the client hello message.  RFC
  74    3546 defines one Server Name type, ôhostnameö.  This draft adds a
  75    second Server Name type, ôemailaddrö.
  76
  77
  78
  79 2.   EmailAddr ServerName Indication
  80
  81    RFC 3546 defines a Server Name Indication as a mechanism for a client
  82    to tell a server the name of the server that it is contacting.  The
  83    Server Name Indication information is helpful when a single server
  84    may be acting as multiple virtual servers.
  85
  86    RFC 3546 defines the structure shown below which is part of the
  87    extended client hello message.
  88
  89       struct {
  90           NameType name_type;
  91           select (name_type) {
  92               case host_name: HostName;
  93           } name;
  94       } ServerName;
  95
  96       enum {
  97           host_name(0), (255)
  98       } NameType;
  99
 100       opaque HostName<1..2^16-1>;
 101
 102       struct {
 103           ServerName server_name_list<1..2^16-1>
 104       } ServerNameList;
 105
 106
 107
 108
 109 Crall                    Expires û March 2004                 [Page 2]
 110 \f                   draft-ietf-tls-emailaddr-00.txt     September 2003
 111
 112
 113    This draft proposes a new NameType be added, ôemail_addrö.  As with
 114    host_name, email_addr is used to identify the appropriate virtual
 115    server and therefore help the server select the appropriate
 116    certificate to return to the client.  Therefore, the new structure
 117    looks like the following:
 118
 119
 120       struct {
 121           NameType name_type;
 122           select (name_type) {
 123               case host_name: HostName;
 124               case email_name: EmailName;
 125           } name;
 126       } ServerName;
 127
 128       enum {
 129           host_name(0), email_name(1),(255)
 130       } NameType;
 131
 132       opaque HostName<1..2^16-1>;
 133
 134       opaque EmailName<1..2^16-1>;
 135
 136       struct {
 137           ServerName server_name_list<1..2^16-1>
 138       } ServerNameList;
 139
 140
 141    The syntax of EmailName MUST conform to email addresses as defined in
 142    RFC 822 [RFC822].
 143
 144 3.   Error Alerts
 145    The new alert, ôunrecognized_nameö defined in RFC 3546 should be
 146    returned by the server when the server name is unrecognized, whether
 147    the name is a HostName or an EmailName.  As stated in RFC 3546, this
 148    error may be fatal.
 149
 150 4.   Security Considerations
 151
 152    The security considerations for the new EmailName are similar to
 153    those of the HostName in RFC 3546.
 154
 155    The server receiving an extended client hello message with an
 156    EmailName MUST ensure the name does not cause a buffer overflow
 157    within the server.
 158
 159    The EmailName supports internationalized hostnames.  However, this
 160    specification does not deal with security issues of internationalized
 161    names.
 162
 163
 164 Crall                    Expires û March 2004                 [Page 3]
 165 \f                   draft-ietf-tls-emailaddr-00.txt     September 2003
 166
 167
 168
 169
 170 5.   Acknowledgments
 171
 172    The authors wish to thank the authors of RFC 3546 for their help.
 173
 174
 175 6.   AuthorsÆ Addresses
 176
 177    John Banes
 178    Microsoft
 179    Email: jbanes@microsoft.com
 180
 181    Chris Crall
 182    Microsoft
 183    Email: ccrall@microsoft.com
 184
 185
 186 7.   Normative References
 187
 188
 189    [KEYWORDS] Bradner, S., ôKey words for use in RFCs to Indicate
 190       Requirement Levelsö, BCP 14, RFC 2119, March 1997
 191
 192    [RFC822] Crocker, D., ôStandard for the Format of ARPA Internet Text
 193       Messagesö, RFC 822, August 1982
 194
 195    [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwwod, D., Mikkelsen, J.
 196       and Wright, T., ôTransport Layer Security (TLS) Extensionsö, RFC
 197       3546, June 2003
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219 Crall                    Expires û March 2004                 [Page 4]
 220 \f