1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
|
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]
|
