3
NETWORK WORKING GROUP L. Zhu
4
Internet-Draft Microsoft Corporation
5
Updates: 4120 (if approved) J. Altman
6
Intended status: Standards Track Secure Endpoints
7
Expires: January 10, 2008 July 9, 2007
10
Initial and Pass Through Authentication Using Kerberos V5 and the GSS-
16
By submitting this Internet-Draft, each author represents that any
17
applicable patent or other IPR claims of which he or she is aware
18
have been or will be disclosed, and any of which he or she becomes
19
aware will be disclosed, in accordance with Section 6 of BCP 79.
21
Internet-Drafts are working documents of the Internet Engineering
22
Task Force (IETF), its areas, and its working groups. Note that
23
other groups may also distribute working documents as Internet-
26
Internet-Drafts are draft documents valid for a maximum of six months
27
and may be updated, replaced, or obsoleted by other documents at any
28
time. It is inappropriate to use Internet-Drafts as reference
29
material or to cite them other than as "work in progress."
31
The list of current Internet-Drafts can be accessed at
32
http://www.ietf.org/ietf/1id-abstracts.txt.
34
The list of Internet-Draft Shadow Directories can be accessed at
35
http://www.ietf.org/shadow.html.
37
This Internet-Draft will expire on January 10, 2008.
41
Copyright (C) The IETF Trust (2007).
45
This document defines extensions to the Kerberos protocol and the
46
GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to
47
exchange messages with the KDC using the GSS-API acceptor as the
48
proxy, by encapsulating the Kerberos messages inside GSS-API tokens.
49
With these extensions a client can obtain Kerberos tickets for
50
services where the KDC is not accessible to the client, but is
54
Zhu & Altman Expires January 10, 2008 [Page 1]
56
Internet-Draft IAKERB July 2007
59
accessible to the application server.
64
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
65
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
66
3. GSS-API Encapsulation . . . . . . . . . . . . . . . . . . . . 3
67
4. Addresses in Tickets . . . . . . . . . . . . . . . . . . . . . 7
68
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
69
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
70
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
71
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
72
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
73
8.2. Informative references . . . . . . . . . . . . . . . . . . 9
74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
75
Intellectual Property and Copyright Statements . . . . . . . . . . 11
110
Zhu & Altman Expires January 10, 2008 [Page 2]
112
Internet-Draft IAKERB July 2007
117
When authenticating using Kerberos V5, clients obtain tickets from a
118
KDC and present them to services. This model of operation cannot
119
work if the client does not have access to the KDC. For example, in
120
remote access scenarios, the client must initially authenticate to an
121
access point in order to gain full access to the network. Here the
122
client may be unable to directly contact the KDC either because it
123
does not have an IP address, or the access point packet filter does
124
not allow the client to send packets to the Internet before it
125
authenticates to the access point.
127
Recent advancements in extending Kerberos permit Kerberos
128
authentication to complete with the assistance of a proxy. The
129
Kerberos [RFC4120] pre-authentication framework [KRB-PAFW] prevents
130
the exposure of weak client keys over the open network. The Kerberos
131
support of anonymity [KRB-ANON] provides for privacy and further
132
complicates traffic analysis. The kdc-referrals option defined in
133
[KRB-PAFW] may reduce the number of messages exchanged while
134
obtaining a ticket to exactly two even in cross-realm
137
Building upon these Kerberos extensions, this document extends
138
[RFC4120] and [RFC4121] such that the client can communicate with the
139
KDC using a Generic Security Service Application Program Interface
140
(GSS-API) [RFC2743] acceptor as the proxy. The GSS-API acceptor
141
relays the KDC request and reply messages between the client and the
142
KDC. The GSS-API acceptor, when relaying the Kerberos messages, is
143
called an IAKERB proxy. Consequently, IAKERB as defined in this
144
document requires the use of GSS-API.
147
2. Conventions Used in This Document
149
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
150
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
151
document are to be interpreted as described in [RFC2119].
154
3. GSS-API Encapsulation
156
The mechanism Objection Identifier (OID) for GSS-API IAKERB, in
157
accordance with the mechanism proposed by [RFC4178] for negotiating
158
protocol variations, is id-kerberos-iakerb:
160
id-kerberos-iakerb ::=
161
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
166
Zhu & Altman Expires January 10, 2008 [Page 3]
168
Internet-Draft IAKERB July 2007
171
The initial context establishment token of IAKERB MUST have the
172
generic token framing described in section 3.1 of [RFC2743] with the
173
mechanism OID being id-kerberos-iakerb, and any subsequent IAKERB
174
context establishment token MUST NOT have this token framing.
176
The client starts by constructing the ticket request, and if the
177
ticket request is being made to the KDC, the client, instead of
178
contacting the KDC directly, encapsulates the request message into
179
the output token of the GSS_Init_security_context() call and returns
180
GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more
181
token is required in order to establish the context. The output
182
token is then passed for use as the input token to the
183
GSS_Accept_sec_context() call in accordance with GSS-API. The GSS-
184
API acceptor extracts the Kerberos request in the input token,
185
locates the target KDC, and sends the request on behalf of the
186
client. After receiving the KDC reply, the GSS-API acceptor then
187
encapsulates the reply message into the output token of
188
GSS_Accept_sec_context(). The GSS-API acceptor returns
189
GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more
190
token is required in order to establish the context. The output
191
token is passed to the initiator in accordance with GSS-API.
193
Client <---------> IAKERB proxy <---------> KDC
195
The innerToken described in section 3.1 of [RFC2743] and subsequent
196
GSS-API mechanism tokens have the following formats: it starts with a
197
two-octet token-identifier (TOK_ID), followed by an IAKERB message or
200
Only one IAKERB specific message, namely the IAKERB_PROXY message, is
201
defined in this document. The TOK_ID values for Kerberos messages
202
are the same as defined in [RFC4121].
204
Token TOK_ID Value in Hex
205
--------------------------------------
208
The content of the IAKERB_PROXY message is defined as an IAKERB-
209
HEADER structure immediately followed by a Kerberos message. The
210
Kerberos message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP,
211
or a KRB-ERROR as defined in [RFC4120].
222
Zhu & Altman Expires January 10, 2008 [Page 4]
224
Internet-Draft IAKERB July 2007
227
IAKERB-HEADER ::= SEQUENCE {
228
target-realm [1] UTF8String,
229
-- The name of the target realm.
230
cookie [2] OCTET STRING OPTIONAL,
231
-- Opaque data, if sent by the server,
232
-- MUST be copied by the client verbatim into
233
-- the next IAKRB_PROXY message.
237
The IAKERB-HEADER structure and all the Kerberos messages MUST be
238
encoded using Abstract Syntax Notation One (ASN.1) Distinguished
239
Encoding Rules (DER) [X680] [X690].
241
The IAKERB client fills out the IAKERB-HEADER structure as follows:
242
the target-realm contains the realm name the ticket request is
243
addressed to. In the initial message from the client, the cookie
244
field is absent. The client MUST specify a target-realm. If the
245
client does not know the realm of the client's true principal name
246
[REFERALS], it MUST specify a realm it knows. This can be the realm
247
of the client's host.
249
Upon receipt of the IAKERB_PROXY message, the GSS-API acceptor
250
inspects the target-realm field in the IAKERB_HEADER, and locates a
251
KDC of that realm, and sends the ticket request to that KDC.
253
When the GSS-API acceptor is unable to obtain an IP address for a KDC
254
in the client's realm, it sends a KRB_ERROR message with the code
255
KRB_AP_ERR_IAKERB_KDC_NOT_FOUND to the client and the context fails
256
to establish. There is no accompanying error data defined in this
257
document for this error code.
259
KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85
260
-- The IAKERB proxy could not find a KDC.
262
When the GSS-API acceptor has an IP address for a KDC in the client
263
realm, but does not receive a response from any KDC in the realm
264
(including in response to retries), it sends a KRB_ERROR message with
265
the code KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE to the client and the
266
context fails to establish. There is no accompanying error data
267
defined in this document for this error code.
269
KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86
270
-- The KDC did not respond to the IAKERB proxy.
272
The IAKERB proxy can send opaque data in the cookie field of the
273
IAKERB-HEADER structure in the server reply to the client, in order
274
to, for example, minimize the amount of state information kept by the
278
Zhu & Altman Expires January 10, 2008 [Page 5]
280
Internet-Draft IAKERB July 2007
283
GSS-API acceptor. The content and the encoding of the cookie field
284
is a local matter of the IAKERB proxy. The client MUST copy the
285
cookie verbatim from the previous server response whenever the cookie
286
is present into the subsequent tokens that contains an IAKERB_PROXY
289
When the client obtained a service ticket, the client sends a
290
KRB_AP_REQ message to the server, and performs the client-server
291
application exchange as defined in [RFC4120] and [RFC4121].
293
For implementations comforming to this specification, the
294
authenticator subkey in the AP-REQ MUST alway be present, and the
295
Exts field in the GSS-API authenticator [GSS-EXTS] MUST contain an
296
extension of the type GSS_EXTS_IAKERB_FINISHED and the extension data
297
contains the ASN.1 DER encoding of the structure IAKERB-FINISHED.
299
GSS_EXTS_IAKERB_FINISHED TBD
300
--- Data type for the IAKERB checksum.
302
IAKERB-FINISHED ::= {
303
iakerb-messages [1] Checksum,
304
-- Contains the checksum of the GSS-API tokens
305
-- exchanged between the initiator and the acceptor,
306
-- and prior to the containing AP_REQ GSS-API token.
307
-- The checksum is performed over the GSS-API tokens
308
-- in the order that the tokens were sent.
312
The iakerb-messages field in the IAKERB-FINISHED structure contains a
313
checksum of all the GSS-API tokens exchanged between the initiator
314
and the acceptor, and prior to the GSS-API token containing the
315
AP_REQ. This checksum is performed over these GSS-API tokens in the
316
order that the tokens were sent. In the parlance of [RFC3961], the
317
checksum type is the required checksum type for the enctype of the
318
subkey in the authenticator, the protocol key for the checksum
319
operation is the authenticator subkey, and the key usage number is
320
KEY_USAGE_IAKERB_FINISHED.
322
KEY_USAGE_IAKERB_FINISHED 42
324
The GSS-API acceptor MUST then verify the checksum contained in the
325
GSS_EXTS_IAKERB_FINISHED extension. This checksum provides integrity
326
protection for the messages exchanged including the unauthenticated
327
clear texts in the IAKERB-HEADER structure.
329
If the pre-authentication data is encrypted in the long-term
330
password-based key of the principal, the risk of security exposures
334
Zhu & Altman Expires January 10, 2008 [Page 6]
336
Internet-Draft IAKERB July 2007
339
is significant. Implementations SHOULD provide the AS_REQ armoring
340
as defined in [KRB-PAFW] unless an alternative protection is
341
deployed. In addition, the anonymous Kerberos FAST option is
342
RECOMMENDED for the client to complicate traffic analysis.
345
4. Addresses in Tickets
347
In IAKERB, the machine sending requests to the KDC is the GSS-API
348
acceptor and not the client. As a result, the client should not
349
include its addresses in any KDC requests for two reasons. First,
350
the KDC may reject the forwarded request as being from the wrong
351
client. Second, in the case of initial authentication for a dial-up
352
client, the client machine may not yet possess a network address.
353
Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and
354
TGS-REQ requests SHOULD be blank and the caddr field of the ticket
355
SHOULD similarly be left blank.
358
5. Security Considerations
360
A typical IAKERB client sends the AS_REQ with pre-authentication data
361
encrypted in the long-term keys of the user before the server is
362
authenticated. This enables offline attacks by un-trusted servers.
363
To mitigate this threat, the client SHOULD use Kerberos
364
FAST[KRB-PAFW] and require KDC authentication to protect the user's
367
The client name is in clear text in the authentication exchange
368
messages and ticket granting service exchanges according to [RFC4120]
369
whereas the client name is encrypted in client- server application
370
exchange messages. By using the IAKERB proxy to relay the ticket
371
requests and responses, the client's identity could be revealed in
372
the client-server traffic where the same identity could have been
373
concealed if IAKERB were not used. Hence, to complicate traffic
374
analysis and provide privacy for the IAKERB client, the IAKERB client
375
SHOULD request the anonymous Kerberos FAST option [KRB-PAFW].
377
Similar to other network access protocols, IAKERB allows an
378
unauthenticated client (possibly outside the security perimeter of an
379
organization) to send messages that are proxied to interior servers.
381
In a scenario where DNS SRV RR's are being used to locate the KDC,
382
IAKERB is being used, and an external attacker can modify DNS
383
responses to the IAKERB proxy, there are several countermeasures to
384
prevent arbitrary messages from being sent to internal servers:
390
Zhu & Altman Expires January 10, 2008 [Page 7]
392
Internet-Draft IAKERB July 2007
395
1. KDC port numbers can be statically configured on the IAKERB
396
proxy. In this case, the messages will always be sent to KDC's.
397
For an organization that runs KDC's on a static port (usually
398
port 88) and does not run any other servers on the same port,
399
this countermeasure would be easy to administer and should be
402
2. The proxy can do application level sanity checking and filtering.
403
This countermeasure should eliminate many of the above attacks.
405
3. DNS security can be deployed. This countermeasure is probably
406
overkill for this particular problem, but if an organization has
407
already deployed DNS security for other reasons, then it might
408
make sense to leverage it here. Note that Kerberos could be used
409
to protect the DNS exchanges. The initial DNS SRV KDC lookup by
410
the proxy will be unprotected, but an attack here is at most a
411
denial of service (the initial lookup will be for the proxy's KDC
412
to facilitate Kerberos protection of subsequent DNS exchanges
413
between itself and the DNS server).
418
Jonathan Trostle, Michael Swift, Bernard Aboba and Glen Zorn wrote
419
earlier revision of this document.
421
The hallway conversations between Larry Zhu and Nicolas Williams
422
formed the basis of this document.
425
7. IANA Considerations
427
There is no IANA action required for this document.
432
8.1. Normative References
435
Emery, S., "Kerberos Version 5 GSS-API Channel Binding
437
draft-ietf-krb-wg-gss-cb-hash-agility-03.txt (work in
440
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
441
Requirement Levels", BCP 14, RFC 2119, March 1997.
446
Zhu & Altman Expires January 10, 2008 [Page 8]
448
Internet-Draft IAKERB July 2007
451
[RFC2743] Linn, J., "Generic Security Service Application Program
452
Interface Version 2, Update 1", RFC 2743, January 2000.
454
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
455
Kerberos 5", RFC 3961, February 2005.
457
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
458
Kerberos Network Authentication Service (V5)", RFC 4120,
461
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
462
Version 5 Generic Security Service Application Program
463
Interface (GSS-API) Mechanism: Version 2", RFC 4121,
466
[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
467
Simple and Protected Generic Security Service Application
468
Program Interface (GSS-API) Negotiation Mechanism",
469
RFC 4178, October 2005.
471
8.2. Informative references
474
Zhu, L. and P. Leach, "Kerberos Anonymity Support",
475
draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
478
Zhu, L. and S. Hartman, "A Generalized Framework for
479
Kerberos Pre-Authentication",
480
draft-ietf-krb-wg-preauth-framework-06.txt (work in
487
Microsoft Corporation
492
Email: lzhu@microsoft.com
502
Zhu & Altman Expires January 10, 2008 [Page 9]
504
Internet-Draft IAKERB July 2007
513
Email: jaltman@secure-endpoints.com
558
Zhu & Altman Expires January 10, 2008 [Page 10]
560
Internet-Draft IAKERB July 2007
563
Full Copyright Statement
565
Copyright (C) The IETF Trust (2007).
567
This document is subject to the rights, licenses and restrictions
568
contained in BCP 78, and except as set forth therein, the authors
569
retain all their rights.
571
This document and the information contained herein are provided on an
572
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
573
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
574
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
575
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
576
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
577
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
580
Intellectual Property
582
The IETF takes no position regarding the validity or scope of any
583
Intellectual Property Rights or other rights that might be claimed to
584
pertain to the implementation or use of the technology described in
585
this document or the extent to which any license under such rights
586
might or might not be available; nor does it represent that it has
587
made any independent effort to identify any such rights. Information
588
on the procedures with respect to rights in RFC documents can be
589
found in BCP 78 and BCP 79.
591
Copies of IPR disclosures made to the IETF Secretariat and any
592
assurances of licenses to be made available, or the result of an
593
attempt made to obtain a general license or permission for the use of
594
such proprietary rights by implementers or users of this
595
specification can be obtained from the IETF on-line IPR repository at
596
http://www.ietf.org/ipr.
598
The IETF invites any interested party to bring to its attention any
599
copyrights, patents or patent applications, or other proprietary
600
rights that may cover technology that may be required to implement
601
this standard. Please address the information to the IETF at
607
Funding for the RFC Editor function is provided by the IETF
608
Administrative Support Activity (IASA).
614
Zhu & Altman Expires January 10, 2008 [Page 11]
added
removed
doc/standardisation/draft-zhu-ws-kerb-03.txt
