-
Notifications
You must be signed in to change notification settings - Fork 0
/
rfc.xml
300 lines (295 loc) · 11.7 KB
/
rfc.xml
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
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
<?xml version="1.0" encoding="US-ASCII"?>
<rfc
xmlns:xi="http://www.w3.org/2001/XInclude"
category="std"
docName="draft-vankleef-ssh-hostname-extension-00"
ipr="trust200902"
submissionType="IETF"
consensus="true"
updates="4252">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc private="SSH VHost extension" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<front>
<title abbrev="SSH VHost extension">
Accessing a Virtual Host over SSH
</title>
<seriesInfo
name="Internet-Draft"
status="experimental"
value="draft-vankleef-ssh-hostname-extension-00"/>
<!--<seriesInfo
name="ISSN"
value="2070-1721"/>-->
<author
fullname="Rolf van Kleef"
initials="R. H. B."
role="editor"
surname="van Kleef">
<organization>Individual Contributor</organization>
<address>
<email>[email protected]</email>
<uri>https://rolfvankleef.nl/</uri>
</address>
</author>
<area>int</area>
<area>tsv</area>
<keyword>SSH</keyword>
<keyword>HOST</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>
This document describes an extension for the
<tt>SSH_MSG_USERAUTH_REQUEST</tt> as defined in section 5 of RFC 4252
that allows an SSH server to identify which virtual host a client is
attempting to connect to.
It ensures that unextended clients can interoperate with extended
servers and vice-versa, albeit without the features provided as a
result of this document.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Many application-layer protocols already have means of specifying which
"virtual host" a client intends to connects to.
Examples are the HTTP 'Host' header as specified by
<xref target="IANA_MH">the IANA Message Headers</xref> list, and the
<xref target="RFC7151">FTP HOST command</xref>.
Most of these implementations note that it is used to identify different
virtual hosts where multiple DNS names resolve to one IP address.
The goal of this document is to make it possible to implement similar
features to SSH by enhancing the 'username' field in the user
authentication packet (<tt>SSH_MSG_USERAUTH_REQUEST</tt>) as defined
in <xref target="RFC4252" section="5" sectionFormat="of"/> so that it
can be used to specify to which virtual host the client means to
connect.
</t>
</section>
<section title="Conventions Used in This Document">
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this
document are to be interpreted as described in
<xref target="RFC2119"/>.
</t>
<t>
Throughout this document, when the fields are referenced, they will
appear within single quotes.
When values to fill those fields are referenced, they will appear
within double quotes.
Using the above example, possible values for 'data' are "foo" and
"bar".
</t>
<t>
The required syntax is defined using the Augmented BNF defined in
<xref target="RFC5234"/>.
</t>
<t>
With the increased use of virtualization technologies, there may be
several possible definitions for the term "virtual host".
This document follows the definition from
<xref target="RFC3875" section="4.1.14" sectionFormat="of"/>, where
several virtual hosts share the same IP address, and hostnames are used
by the server-SSH process to route sessions to the appropriate virtual
host.
</t>
</section>
<section title="Updates for SSH_MSG_USERAUTH_REQUEST">
<t>
This document proposes the name of the virtual host be placed in the
'username' field of the <tt>SSH_MSG_USERAUTH_REQUEST</tt> message
next to the actual username.
</t>
<section title="Syntax of the 'username' Field">
<t>
The method of embedding the name of the virtual host in the
'username' field of the aforementioned packet is separating the
username and the name of the virtual host by an "@"-sign.
The name of the virtual host <bcp14>MUST</bcp14> be a valid
hostname as specified by
<xref target="RFC3986" section="3.2.2" sectionFormat="of"/>.
</t>
<t>
It should still be possible to simply specify a username without a
specification of a virtual host.
If this is wanted, an "@"-sign <bcp14>MUST</bcp14> be appended to the
username, unless the username does not contain an "@"-sign, in which
case, an "@"-sign <bcp14>SHOULD NOT</bcp14> be appended to the
username.
</t>
<t>
Formalizing the preceding text, the value of the 'username' field
of the <tt>SSH_MSG_USERAUTH_REQUEST</tt> will conform to this
grammar:
</t>
<figure>
<name>'username' field grammar</name>
<sourcecode type="abnf" name="'username' field grammar">
username_value = username "@" virtual_host_name
username_value =/ username "@"
username_value =/ username_noat
username = 1*(%x01-%x10FFFF)
username_noat = 1*(%x01-%x39 / %x41-%x10FFFF)
virtual_host_name = <See section 3.2.2 of RFC3986></sourcecode>
</figure>
<t>
When this grammar, with the root symbol of 'username_value' is used
to parse the 'username' field, the value of the symbol 'username'
or 'username_noat' are to be used as if they are the username, and
the value of the symbol 'virtual_host_name' may be used as the name
of the virtual host, if it is present.
If the symbol 'virtual_host_name' is absent, no virtual host name is
specified.
</t>
</section>
<section title="Examples">
<table>
<name>Examples of values in the 'username' field</name>
<thead>
<tr>
<th>Transmitted string</th>
<th>Actual username</th>
<th>Actual host</th>
</tr>
</thead>
<tbody>
<tr>
<td><tt>[email protected]</tt></td>
<td><tt>user</tt></td>
<td><tt>host.example</tt></td>
</tr>
<tr>
<td><tt>user@@host.example</tt></td>
<td><tt>user@</tt></td>
<td><tt>host.example</tt></td>
</tr>
<tr>
<td><tt>user</tt></td>
<td><tt>user</tt></td>
<td></td>
</tr>
<tr>
<td><tt>user@[email protected]</tt></td>
<td><tt>user@name</tt></td>
<td><tt>host.example</tt></td>
</tr>
<tr>
<td><tt>user@x@@</tt></td>
<td><tt>user@x@</tt></td>
<td></td>
</tr>
<tr>
<td><tt>user@[ff::ff]</tt></td>
<td><tt>user</tt></td>
<td><tt>[ff::ff]</tt></td>
</tr>
</tbody>
</table>
</section>
</section>
<section title="Interoperability">
<t>
It is essential that older implementations of SSH servers and clients
will keep working, even when the other party does support the protocol
alterations as described in this document.
It is acceptable to fall back to the behaviour and featureset of the
SSH protocol without the features and behaviours resulting from the
extension described in this document.
In order to do this, this document describes an extension which can be
either present or absent.
In order to communicate to the other party whether this extension is
supported, the negotiation protocol as described in
<xref target="RFC8308"/> is used with the extension name as discussed
in <xref target="iana_additions"/>.
</t>
<t>
When a new client is used to connect to a server that does not support
the extension described in this document, the client
<bcp14>MUST NOT</bcp14> submit a name of the virtual host and
<bcp14>MUST NOT</bcp14> append the username with an "@"-sign.
Any services that depend on the specification of a virtual host can
be expected to be absent or dysfunctional, and should not be
requested.
</t>
<t>
When the server detects a client that does not support the
extension described in this document, the server
<bcp14>MUST</bcp14> interpret the username field as if it is a username
in its entirity, without attempting to split out a hostname.
The server should then proceed as if no virtual host was specified by
the client.
</t>
</section>
<section title="IANA Considerations">
<section
anchor="iana_additions"
title="Additions to Existing Registries">
<t>
Under the "Secure Shell (SSH) Protocol Parameters, Extension Names"
registry as defined in
<xref target="RFC8308" section="4.2" sectionFormat="of"/>,
IANA is requested to assign the proposed extension name 'virtualhost'
to be used as described in this document.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
All the credentials are submitted over a secure line.
That means that the name of the virtual host is submitted over a secure
transport as well.
The extension information is not submitted over a secure line.
It is, in fact, submitted over plaintext.
That means that a potential attacker could override advertised support,
or lack thereof, of the extension described in this document.
This does not introduce a critical security issue, as overriding
this will very likely cause a failed authentication, either because
the requested user does not exist on the server, or because the
credentials used are not valid for the requested user.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<xi:include
href="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include
href="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
<xi:include
href="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4252.xml"/>
<xi:include
href="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
<xi:include
href="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7151.xml"/>
<xi:include
href="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8308.xml"/>
</references>
<references title="Informative References">
<reference
anchor="IANA_MH"
target="https://www.iana.org/assignments/message-headers/message-headers.xhtml">
<front>
<title>IANA Message Header registry</title>
<author>
<organization>Internet Assigned Numbers Authority</organization>
</author>
</front>
</reference>
<xi:include
href="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3875.xml"/>
</references>
</back>
</rfc>
<!-- vim: ts=2:sts=2:sw=2:expandtab
-->