3
NETWORK WORKING GROUP L. Zhu
4
Internet-Draft Microsoft Corporation
5
Updates: 4120 (if approved) October 2006
6
Intended status: Standards Track
10
Kerberos for Web Services
15
By submitting this Internet-Draft, each author represents that any
16
applicable patent or other IPR claims of which he or she is aware
17
have been or will be disclosed, and any of which he or she becomes
18
aware will be disclosed, in accordance with Section 6 of BCP 79.
20
Internet-Drafts are working documents of the Internet Engineering
21
Task Force (IETF), its areas, and its working groups. Note that
22
other groups may also distribute working documents as Internet-
25
Internet-Drafts are draft documents valid for a maximum of six months
26
and may be updated, replaced, or obsoleted by other documents at any
27
time. It is inappropriate to use Internet-Drafts as reference
28
material or to cite them other than as "work in progress."
30
The list of current Internet-Drafts can be accessed at
31
http://www.ietf.org/ietf/1id-abstracts.txt.
33
The list of Internet-Draft Shadow Directories can be accessed at
34
http://www.ietf.org/shadow.html.
36
This Internet-Draft will expire on April 4, 2007.
40
Copyright (C) The Internet Society (2006).
44
This document defines extensions to the Kerberos protocol and the
45
GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to
46
exchange messages with the KDC using the GSS-API acceptor as the
47
proxy, by encapsulating the Kerberos messages inside GSS-API tokens.
48
With these extensions, Kerberos is suitable for securing
49
communication between the client and web services over the Internet.
54
Zhu Expires April 4, 2007 [Page 1]
56
Internet-Draft WS-KERB October 2006
61
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
62
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
63
3. GSS-API Encapsulation . . . . . . . . . . . . . . . . . . . . . 3
64
4. Addresses in Tickets . . . . . . . . . . . . . . . . . . . . . 6
65
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
66
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
67
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
68
8. Normative References . . . . . . . . . . . . . . . . . . . . . 7
69
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
70
Intellectual Property and Copyright Statements . . . . . . . . . . 9
110
Zhu Expires April 4, 2007 [Page 2]
112
Internet-Draft WS-KERB October 2006
117
The Kerberos [RFC4120] pre-authentication framework [KRB-PAFW]
118
promises minimal or no exposure of weak client keys and strong client
119
authentication. The Kerberos support of anonymity [KRB-ANON]
120
provides for privacy. These advancements make Kerberos suitable over
123
The traditional client-push Kerberos protocol does not work well in
124
the Web services environments where the KDC is not accessible to the
125
client, but is accessible to the web server. For example, the KDC is
126
commonly placed behind a firewall together with the application
127
server. The lack of accessibility to the KDC by the client could
128
also occur are when the client does not have an IP address prior to
129
authenticating to an access point.
131
Generic Security Service Application Program Interface (GSS-API)
132
[RFC2743] allows security mechanisms exchange arbitrary messages
133
between the initiator and the acceptor via the application traffic,
134
independent of the underlying transports. A protocol based on
135
[RFC4121] is thus defined to allow the GSS-API initiator to exchange
136
Kerberos messages with the KDC by using the GSS-API acceptor as the
137
proxy. The acceptor-pull model defined in this specification is
138
benefical for initiators with limited processing power such as mobile
139
devices, or when the transport layer between the initiator and the
140
acceptor has high network latency.
142
Client --------- WS-KERB proxy ---------- KDC
144
The Kerberos client MUST avoid exposure of long term client keys to
145
the GSS-API acceptor, before and after the Kerberos server is
146
authenticated. This can be accomplished by using Kerberos-FAST [KRB-
147
PAFW]. Furthermore, the initiator can use the anonymous option as
148
defined in Section 6.5.2 of [KRB-PAFW], to hide the client identity
149
from adversary who can eavesdrop the application traffic.
152
2. Conventions Used in This Document
154
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
155
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
156
document are to be interpreted as described in [RFC2119].
159
3. GSS-API Encapsulation
161
The mechanism Objection Identifier (OID) for GSS-API WS-KERB, in
162
accordance with the mechanism proposed by [RFC4178] for negotiating
166
Zhu Expires April 4, 2007 [Page 3]
168
Internet-Draft WS-KERB October 2006
171
protocol variations, is id-kerberos-ws.
174
{ iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
177
The first token of the GSS-API WS-KERB mechanism MUST have the
178
generic token framing described in section 3.1 of [RFC2743] with the
179
mechanism OID being id-kerberos-ws, and any subsequent GSS-API WS-
180
KERB token MUST NOT have this framing.
182
The GSS-API WS-KERB mechanism MUST always provide mutual
183
authentication, even if the initiator does not ask for it. When
184
mutual-authentication is performed, the GSS-API acceptor will always
185
send back an AP-REP, and as described later in this section this
186
mechanism provides integrity protection for all initiator-acceptor
187
proxy message exchanges.
189
The innerToken described in section 3.1 of [RFC2743] and subsequent
190
GSS-API tokens have the following formats: it starts with a two-octet
191
token-identifier (TOK_ID), followed by a WS-KERB message or a
195
Token/Message TOK_ID Value in Hex
196
-----------------------------------------
199
Only one WS-KERB specific message, namely the WS_KRB_PROXY message,
200
is defined in this document. The TOK_ID values for [RFC4120]
201
Kerberos messages are the same as those defined for the GSS-API
202
Kerberos mechanism [RFC4121].
204
The message of the WS_KRB_PROXY type is defined as a WS-KRB-HEADER
205
structure immediately followed by a Kerberos message. The Kerberos
206
message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP, or a KRB-
207
ERROR as defined in [RFC4120].
222
Zhu Expires April 4, 2007 [Page 4]
224
Internet-Draft WS-KERB October 2006
227
WS-KRB-HEADER ::= SEQUENCE {
228
proxy-data [1] ProxyData,
232
ProxyData :: = SEQUENCE {
234
cookie [3] OCTET STRING OPTIONAL,
235
-- opaque data, if sent by the acceptor,
236
-- MUST be copied by the client unchanged into
237
-- the next WS-KERB message.
242
The WS-KRB-HEADER structure and all the Kerberos messages MUST be
243
encoded using Abstract Syntax Notation One (ASN.1) Distinguished
244
Encoding Rules (DER) [X680] [X690].
246
The GSS-API initiator fills out the realm field in the ProxyData of
247
the first request with the client realm. If the client does not know
248
the client realm [REFERALS], it MUST fill it out using the client's
249
default realm name such as the realm of the client host. Typically
250
the Kerberos message in the first WS_KRB_PROXY message from the
251
client is an AS-REQ message.
253
Upon receipt of the WS_KRB_PROXY message, the GSS-API WS-KERB
254
acceptor MUST use the proxy-data in the message from the client to
255
locate the KDC and sends the encapsulated Kerberos message to that
256
KDC. Unless otherwise specified, the acceptor can locate the KDC per
257
Section 7.2.3.2 of [RFC4120].
259
In order to reduce the number of roundtrips between the initiator and
260
the acceptor, the acceptor SHOULD process any message exchange with
261
the KDC if the exchange is unauthenticated, such as client-referral
262
message exchange [REFERALS]. If the acceptor can not process the KDC
263
response by itself, for example when the knowledge of the client keys
264
is required, it sends back to the client the KDC reply message
265
encapsulated in a WS_KRB_PROXY message. The acceptor MUST fill out
266
the realm name whose KDC produced the response. The acceptor SHOULD
267
use the kdc-referrals option described in Section 6.5.2 of [KRB-PAFW]
268
to allow the KDC of the client's realm to obtain a service ticket
269
addressed to the acceptor, thus further reduce the number of
270
roundtrips between the GSS-API initiator and the GSS-API acceptor.
271
The GSS-API acceptor can send opaque data in the cookie field of the
272
WS-KRB-HEADER structure in the reply from the acceptor to the
273
initiator, in order to, for example, to facilitate state managements
274
on the GSS-API acceptor. The content and the encoding of the cookie
278
Zhu Expires April 4, 2007 [Page 5]
280
Internet-Draft WS-KERB October 2006
283
field is a local matter of the acceptor. The initiator MUST copy the
284
verbatim cookie from the previous acceptor response, when the cookie
285
is present, whenever it sends an additional WS-KRB-PROXY message to
286
the acceptor. The client processes the KDC response, and fills out
287
the realm name it believes to whom the acceptor should send the
288
encapsulated Kerberos message.
290
When the client obtains a service ticket, the initiator then sends a
291
KRB_AP_REQ message to the acceptor, and proceed as defined in
292
[RFC4121]. A GSS-API authenticator extension [GSS-EXTS] MUST be sent
293
by the initiator. The extension type is 2 and the content is the
294
ASN.1 DER encoding of the type Checksum. The checksum is performed
295
over all GSS-API messages as exchanged between the initiator and the
296
acceptor before the KRB_AP_REQ message, and in the order of the
297
exchange. The checksum type is the required checksum type for the
298
enctype of the subkey in the authenticator, the protocol key is the
299
authenticator subkey, and the key usage number is TBA-1. The
300
acceptor MUST verify this checksum in the GSS-API authenticator
301
extension, then respond with an AP-REP extension [GSS-EXTS]. The AP-
302
REP extension type is 2 and the the content is the ASN.1 DER encoding
303
of the type Checksum. This checksum is performed over all GSS-API
304
messages as exchanged between the initiator and the acceptor before
305
the KRB_AP_REQ message, and in the order of the exchange. The
306
checksum type is the required checksum type for the enctype of the
307
authenticator subkey in the request, and the protocol key is the
308
authenticator subkey, and the key usage number is TBA-2. The
309
initiator MUST then verify this checksum.
312
4. Addresses in Tickets
314
In WS-KERB, the machine sending requests to the KDC is the GSS-API
315
acceptor and not the initiator. As a result, the initiator should
316
not include its addresses in any KDC requests for two reasons.
317
First, the KDC may reject the forwarded request as being from the
318
wrong client. Second, in the case of initial authentication for a
319
dial-up client, the client machine may not yet possess a network
320
address. Hence, as allowed by [RFC4120], the addresses field of the
321
AS-REQ and TGS-REQ requests SHOULD be blank and the caddr field of
322
the ticket SHOULD similarly be left blank.
325
5. Security Considerations
327
Similar to other network access protocols, WS-KERB allows an
328
unauthenticated client (possibly outside the security perimeter of an
329
organization) to send messages that are proxied to interior servers.
334
Zhu Expires April 4, 2007 [Page 6]
336
Internet-Draft WS-KERB October 2006
339
In a scenario where DNS SRV RR's are being used to locate the KDC,
340
WS-KERB is being used, and an external attacker can modify DNS
341
responses to the WS-KERB proxy, there are several countermeasures to
342
prevent arbitrary messages from being sent to internal servers:
344
1. KDC port numbers can be statically configured on the WS-KERB
345
proxy. In this case, the messages will always be sent to KDC's.
346
For an organization that runs KDC's on a static port (usually
347
port 88) and does not run any other servers on the same port,
348
this countermeasure would be easy to administer and should be
351
2. The proxy can do application level sanity checking and filtering.
352
This countermeasure should eliminate many of the above attacks.
354
3. DNS security can be deployed. This countermeasure is probably
355
overkill for this particular problem, but if an organization has
356
already deployed DNS security for other reasons, then it might
357
make sense to leverage it here. Note that Kerberos could be used
358
to protect the DNS exchanges. The initial DNS SRV KDC lookup by
359
the proxy will be unprotected, but an attack here is at most a
360
denial of service (the initial lookup will be for the proxy's KDC
361
to facilitate Kerberos protection of subsequent DNS exchanges
362
between itself and the DNS server).
367
The acceptor-proxy idea is based on the early revisions of this
368
document written by Jonathan Trostle, Michael Swift, Bernard Aboba
371
The rest of the ideas mostly came from hallway conversations between
372
the author and Nicolas Williams.
375
7. IANA Considerations
377
There is no IANA action required for this document.
380
8. Normative References
382
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
383
Requirement Levels", BCP 14, RFC 2119, March 1997.
385
[RFC2743] Linn, J., "Generic Security Service Application Program
386
Interface Version 2, Update 1", RFC 2743, January 2000.
390
Zhu Expires April 4, 2007 [Page 7]
392
Internet-Draft WS-KERB October 2006
395
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
396
Kerberos Network Authentication Service (V5)", RFC 4120,
399
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
400
Version 5 Generic Security Service Application Program
401
Interface (GSS-API) Mechanism: Version 2", RFC 4121,
404
[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
405
Simple and Protected Generic Security Service Application
406
Program Interface (GSS-API) Negotiation Mechanism",
407
RFC 4178, October 2005.
409
[KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity
410
Support", draft-ietf-krb-wg-anon, work in progress.
412
[KRB-PAFW] Zhu, etl, "Kerberos Pre-Authentication framework",
413
draft-ietf-krb-wg-preauth-framework, work in progress.
415
[GSS-EXTS] Emery, S., draft-ietf-krb-wg-gss-cb-hash-agility, work in
418
[REFERALS] Raeburn, K., "Generating KDC Referrals to Locate Kerberos
419
Realms", draft-ietf-krb-wg-kerberos-referrals, work in
422
[X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
423
Information technology - Abstract Syntax Notation One
424
(ASN.1): Specification of basic notation.
426
[X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
427
Information technology - ASN.1 encoding Rules:
428
Specification of Basic Encoding Rules (BER), Canonical
429
Encoding Rules (CER) and Distinguished Encoding Rules
436
Microsoft Corporation
441
Email: lzhu@microsoft.com
447
Zhu Expires April 4, 2007 [Page 8]
449
Internet-Draft WS-KERB October 2006
452
Full Copyright Statement
454
Copyright (C) The Internet Society (2006).
456
This document is subject to the rights, licenses and restrictions
457
contained in BCP 78, and except as set forth therein, the authors
458
retain all their rights.
460
This document and the information contained herein are provided on an
461
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
462
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
463
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
464
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
465
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
466
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
469
Intellectual Property
471
The IETF takes no position regarding the validity or scope of any
472
Intellectual Property Rights or other rights that might be claimed to
473
pertain to the implementation or use of the technology described in
474
this document or the extent to which any license under such rights
475
might or might not be available; nor does it represent that it has
476
made any independent effort to identify any such rights. Information
477
on the procedures with respect to rights in RFC documents can be
478
found in BCP 78 and BCP 79.
480
Copies of IPR disclosures made to the IETF Secretariat and any
481
assurances of licenses to be made available, or the result of an
482
attempt made to obtain a general license or permission for the use of
483
such proprietary rights by implementers or users of this
484
specification can be obtained from the IETF on-line IPR repository at
485
http://www.ietf.org/ipr.
487
The IETF invites any interested party to bring to its attention any
488
copyrights, patents or patent applications, or other proprietary
489
rights that may cover technology that may be required to implement
490
this standard. Please address the information to the IETF at
496
Funding for the RFC Editor function is provided by the IETF
497
Administrative Support Activity (IASA).
503
Zhu Expires April 4, 2007 [Page 9]
added
removed
doc/standardisation/draft-zhu-ws-kerb-01.txt
