7
INTERNET-DRAFT Jonathan Trostle
8
draft-ietf-cat-iakerb-09.txt Cisco Systems
9
Updates: RFC 1510, 1964 Michael Swift
10
October 2002 University of WA
17
Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API
19
<draft-ietf-cat-iakerb-09.txt>
26
This document is an Internet-Draft and is in full conformance with
27
all provisions of Section 10 of RFC2026 [5].
29
Internet-Drafts are working documents of the Internet Engineering
30
Task Force (IETF), its areas, and its working groups. Note that
31
other groups may also distribute working documents as Internet-
34
Internet-Drafts are draft documents valid for a maximum of six months
35
and may be updated, replaced, or obsoleted by other documents at any
36
time. It is inappropriate to use Internet-Drafts as reference
37
material or to cite them other than as "work in progress."
39
The list of current Internet-Drafts can be accessed at
40
http://www.ietf.org/ietf/1id-abstracts.txt
42
The list of Internet-Draft Shadow Directories can be accessed at
43
http://www.ietf.org/shadow.html.
45
This draft expires in March 2003. Please send comments to the
50
This document defines extensions to the Kerberos protocol
51
specification (RFC 1510 [1]) and GSSAPI Kerberos protocol mechanism
52
(RFC 1964 [2]) that enables a client to obtain Kerberos tickets for
53
services where the KDC is not accessible to the client, but is
54
accessible to the application server. Some common scenarios where
55
lack of accessibility would occur are when the client does not have
56
an IP address prior to authenticating to an access point, the client
57
is unable to locate a KDC, or a KDC is behind a firewall. The
58
document specifies two protocols to allow a client to exchange KDC
59
messages (which are GSS encapsulated) with an IAKERB proxy instead of
64
Trostle, Swift, Aboba, Zorn [Page 1]
66
INTERNET DRAFT October 2002 Expires March 2003
69
2. Conventions used in this document
71
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
72
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
73
document are to be interpreted as described in RFC2119 [6].
77
When authenticating using Kerberos V5, clients obtain tickets from a
78
KDC and present them to services. This method of operation works well
79
in many situations, but is not always applicable. The following is a
80
list of some of the scenarios that this proposal addresses:
82
(1) The client must initially authenticate to an access point in
83
order to gain full access to the network. Here the client may be
84
unable to directly contact the KDC either because it does not have an
85
IP address, or the access point packet filter does not allow the
86
client to send packets to the Internet before it authenticates to the
89
(2) A KDC is behind a firewall so the client will send Kerberos
90
messages to the IAKERB proxy which will transmit the KDC request and
91
reply messages between the client and the KDC. (The IAKERB proxy is a
92
special type of Kerberos application server that also relays KDC
93
request and reply messages between a client and the KDC).
97
This proposal specifies two protocols that address the above
98
scenarios: the IAKERB proxy option and the IAKERB minimal messages
99
option. In the IAKERB proxy option (see Figure 1) an application
100
server called the IAKERB proxy acts as a protocol gateway and proxies
101
Kerberos messages back and forth between the client and the KDC. The
102
IAKERB proxy is also responsible for locating the KDC and may
103
additionally perform other application proxy level functions such as
104
auditing. A compliant IAKERB proxy MUST implement the IAKERB proxy
108
Client <---------> IAKERB proxy <----------> KDC
111
Figure 1: IAKERB proxying
113
The second protocol is the minimal messages protocol which is based
114
on user-user authentication [4]; this protocol is targetted at
115
environments where the number of messages, prior to key
116
establishment, needs to be minimized. In the normal minimal messages
117
protocol, the client sends its ticket granting ticket (TGT) to the
118
IAKERB proxy (in a KRB_TKT_PUSH message) for the TGS case. The IAKERB
119
proxy then sends a TGS_REQ to the KDC with the client's TGT in the
120
additional tickets field of the TGS_REQ message. The returned ticket
121
will list the client as the ticket's server principal, and will be
122
encrypted with the session key from the client's TGT. The IAKERB
126
Trostle, Swift, Aboba, Zorn [Page 2]
128
INTERNET DRAFT October 2002 Expires March 2003
131
proxy then uses this ticket to generate an AP request that is sent to
132
the client (see Figure 2). Thus mutual authentication is accomplished
133
with three messages between the client and the IAKERB proxy versus
134
four or more (the difference is larger if crossrealm operations are
137
Subsequent to mutual authentication and key establishment, the IAKERB
138
proxy sends a ticket to the client (in a KRB_TKT_PUSH message). This
139
ticket is created by the IAKERB proxy and contains the same fields as
140
the original service ticket that the proxy sent in the AP_REQ
141
message, except the client and server names are reversed and it is
142
encrypted in a long term key known to the IAKERB proxy. Its purpose
143
is to enable fast subsequent re-authentication by the client to the
144
application server (using the conventional AP request AP reply
145
exchange) for subsequent sessions. In addition to minimizing the
146
number of messages, a secondary goal is to minimize the number of
147
bytes transferred between the client and the IAKERB proxy prior to
148
mutual authentication and key establishment. Therefore, the final
149
service ticket (the reverse ticket) is sent after mutual
150
authentication and key establishment is complete, rather than as part
151
of the initial AP_REQ from the IAKERB proxy to the client. Thus
152
protected application data (e.g., GSS signed and wrapped messages)
153
can flow before this final message is sent.
155
The AS_REQ case for the minimal messages option is similar, where the
156
client sends up the AS_REQ message and the IAKERB proxy forwards it
157
to the KDC. The IAKERB proxy pulls the client TGT out of the AS_REP
158
message; the protocol now proceeds as in the TGS_REQ case described
159
above with the IAKERB proxy including the client's TGT in the
160
additional tickets field of the TGS_REQ message.
162
A compliant IAKERB proxy MUST implement the IAKERB proxy protocol,
163
and MAY implement the IAKERB minimal message protocol. In general,
164
the existing Kerberos paradigm where clients contact the KDC to
165
obtain service tickets should be preserved where possible.
167
For most IAKERB scenarios, such as when the client does not have an
168
IP address, or cannot directly contact a KDC, the IAKERB proxy
169
protocol should be adequate. If the client needs to obtain a
170
crossrealm TGT (and the conventional Kerberos protocol cannot be
171
used), then the IAKERB proxy protocol must be used. In a scenario
172
where the client does not have a service ticket for the target
173
server, it is crucial that the number of messages between the client
174
and the target server be minimized (especially if the client and
175
target server are in different realms), and/or it is crucial that the
176
number of bytes transferred between the client and the target server
177
be minimized, then the client should consider using the minimal
178
messages protocol. The reader should see the security considerations
179
section regarding the minimal messages protocol.
188
Trostle, Swift, Aboba, Zorn [Page 3]
190
INTERNET DRAFT October 2002 Expires March 2003
193
Client --------> IAKERB proxy
196
Client IAKERB proxy --------------------> KDC
198
TGT as additional TGT
200
Client IAKERB proxy <-------------------- KDC
204
Client <-------- IAKERB proxy KDC
207
Client --------> IAKERB proxy KDC
210
-------------------------------------------------------------
211
post-key establishment and application data flow phase:
213
Client <-------- IAKERB proxy KDC
214
TKT_PUSH (w/ticket targetted at IAKERB proxy
215
to enable fast subsequent authentication)
218
Figure 2: IAKERB Minimal Messages Option: TGS case
222
5. GSSAPI Encapsulation
224
The mechanism ID for IAKERB proxy GSS-API Kerberos, in accordance
225
with the mechanism proposed by SPNEGO [7] for negotiating protocol
226
variations, is: {iso(1) org(3) dod(6) internet(1) security(5)
227
mechanisms(5) iakerb(10) iakerbProxyProtocol(1)}. The proposed
228
mechanism ID for IAKERB minimum messages GSS-API Kerberos, in
229
accordance with the mechanism proposed by SPNEGO for negotiating
230
protocol variations, is: {iso(1) org(3) dod(6) internet(1)
231
security(5) mechanisms(5) iakerb(10)
232
iakerbMinimumMessagesProtocol(2)}.
234
NOTE: An IAKERB implementation does not require SPNEGO in order to
235
achieve interoperability with other IAKERB peers. Two IAKERB
236
implementations may interoperate in the same way that any two peers
237
can interoperate using a pre-established GSSAPI mechanism. The above
238
OID's allow two SPNEGO peers to securely negotiate IAKERB from among
239
a set of GSS mechanisms.
241
The AS request, AS reply, TGS request, and TGS reply messages are all
242
encapsulated using the format defined by RFC1964 [2]. This consists
243
of the GSS-API token framing defined in appendix B of [3]:
250
Trostle, Swift, Aboba, Zorn [Page 4]
252
INTERNET DRAFT October 2002 Expires March 2003
255
InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
257
-- MechType is OBJECT IDENTIFIER
258
-- representing iakerb proxy or iakerb min messages
259
innerContextToken ANY DEFINED BY thisMech
260
-- contents mechanism-specific;
261
-- ASN.1 usage within innerContextToken
265
The innerContextToken consists of a 2-byte TOK_ID field (defined
266
below), followed by the Kerberos V5 KRB_AS_REQ, KRB_AS_REP,
267
KRB_TGS_REQ, or KRB_TGS_REP messages, as appropriate. The TOK_ID
268
field shall be one of the following values, to denote that the
269
message is either a request to the KDC or a response from the KDC.
279
We also define the token ID for the KRB_TKT_PUSH token (defined below
280
and used in the minimal messages variation):
286
For completeness, we list the other RFC 1964 defined token ID's here:
296
6. The IAKERB proxy protocol
298
The IAKERB proxy will proxy Kerberos KDC request, KDC reply, and
299
KRB_ERROR messages back and forth between the client and the KDC as
300
illustrated in Figure 1. Messages received from the client must first
301
have the Kerberos GSS header (RFC1964 [2]) stripped off. The
302
unencapsulated message will then be forwarded to a KDC. The IAKERB
303
proxy is responsible for locating an appropriate KDC using the realm
304
information in the KDC request message it received from the client.
305
In addition, the IAKERB proxy SHOULD implement a retry algorithm for
306
KDC requests over UDP (including selection of alternate KDC's if the
307
initial KDC does not respond to its requests). For messages sent by
308
the KDC, the IAKERB proxy encapsulates them with a Kerberos GSS
312
Trostle, Swift, Aboba, Zorn [Page 5]
314
INTERNET DRAFT October 2002 Expires March 2003
317
header before sending them to the client.
319
We define two new Kerberos error codes that allow the proxy to
320
indicate the following error conditions to the client:
322
(a) when the proxy is unable to obtain an IP address for a KDC in the
323
client's realm, it sends the KRB_IAKERB_ERR_KDC_NOT_FOUND KRB_ERROR
324
(80) message to the client.
326
(b) when the proxy has an IP address for a KDC in the client realm,
327
but does not receive a response from any KDC in the realm (including
328
in response to retries), it sends the KRB_IAKERB_ERR_KDC_NO_RESPONSE
329
KRB_ERROR (81) message to the client.
331
To summarize, the sequence of steps for processing is as follows:
335
1. For received KDC_REQ messages (with token ID 00 03)
336
- process GSS framing (check OID)
337
if the OID is not one of the two OID's specified in the GSSAPI
338
Encapsulation section above, then process according to mechanism
339
defined by that OID (if the OID is recognized). The processing
340
is outside the scope of this specification. Otherwise, strip
342
- find KDC for specified realm (if KDC IP address cannot be
343
obtained, send a KRB_ERROR message with error code
344
KRB_IAKERB_ERR_KDC_NOT_FOUND to the client).
345
- send to KDC (storing client IP address, port, and indication
346
whether IAKERB proxy option or minimal messages option is
348
- retry with same or another KDC if no response is received. If
349
the retries also fail, send an error message with error code
350
KRB_IAKERB_ERR_KDC_NO_RESPONSE to the client.
352
2. For received KDC_REP messages
353
- encapsulate with GSS framing, using token ID 01 03 and the OID
354
that corresponds to the stored protocol option
355
- send to client (using the stored client IP address and port)
357
3. For KRB_ERROR messages received from the KDC
358
- encapsulate with GSS framing, using token ID 03 00 and the OID
359
that corresponds to the stored protocol option
360
- send to client (using the stored client IP address and port)
361
(one possible exception is the KRB_ERR_RESPONSE_TOO_BIG error
362
which can lead to a retry of the KDC_REQ message over the TCP
363
transport by the server, instead of simply proxying the error
366
4. For sending/receiving AP_REQ and AP_REP messages
367
- process per RFC 1510 and RFC 1964; the created AP_REP message
368
SHOULD include the subkey (with same etype as the session key)
369
to facilitate use with other key derivation algorithms outside
370
of [2]. The subkey SHOULD be created using locally generated
374
Trostle, Swift, Aboba, Zorn [Page 6]
376
INTERNET DRAFT October 2002 Expires March 2003
379
entropy as one of the inputs (in addition to other inputs
380
such as the session key).
384
1. For sending KDC_REQ messages
385
- create AS_REQ or TGS_REQ message
386
- encapsulate with GSS framing (token ID 00 03 and OID
387
corresponding to the protocol option).
390
2. For received KDC_REP messages
391
- decapsulate by removing GSS framing (token ID 01 03)
392
- process inner Kerberos message according to RFC 1510
394
3. For received KRB_ERROR messages
395
- decapsulate by removing GSS framing (token ID 03 00)
396
- process inner Kerberos message according to RFC 1510
397
and possibly retry the request (time skew errors lead
398
to retries in most existing Kerberos implementations)
400
4. For sending/receiving AP_REQ and AP_REP messages
401
- process per RFC 1510 and RFC 1964; the created AP_REQ
402
message SHOULD include the subsession key in the
405
7. The IAKERB minimal messages protocol
407
The client MAY initiate the IAKERB minimal messages variation when
408
the number of messages must be minimized (the most significant
409
reduction in the number of messages can occur when the client and the
410
IAKERB proxy are in different realms). SPNEGO [7] MAY be used to
411
securely negotiate between the protocols (and amongst other GSS
412
mechanism protocols). A compliant IAKERB server MAY support the
413
IAKERB minimal messages protocol.
415
(a) AS_REQ case: (used when the client does not have a TGT)
417
We apply the Kerberos user-user authentication protocol [4] in this
418
scenario (other work in this area includes the IETF work in progress
419
effort to apply Kerberos user user authentication to DHCP
422
The client indicates that the minimal message sub-protocol will be
423
used by using the appropriate OID as described above. The client
424
sends the GSS encapsulated AS_REQ message to the IAKERB proxy, and
425
the IAKERB proxy processes the GSS framing (as described above for
426
the IAKERB proxy option) and forwards the AS_REQ message to the KDC.
428
The IAKERB proxy will either send a KRB_ERROR message back to the
429
client, or it will send an initial context token consisting of the
430
GSS header (minimal messages OID with a two byte token header 01 03),
431
followed by an AS_REP message. The AS_REP message will contain the
432
AP_REQ message in a padata field; the ticket in the AP_REQ is a
436
Trostle, Swift, Aboba, Zorn [Page 7]
438
INTERNET DRAFT October 2002 Expires March 2003
441
user-user ticket encrypted in the session key from the client's
442
original TGT. We define the padata type PA-AP-REQ with type number
443
25. The corresponding padata value is the AP_REQ message without any
444
GSS framing. For the IAKERB minimal messages AS option, the AP_REQ
445
message authenticator MUST include the RFC 1964 [2] checksum. The
446
mutual-required and use-session-key flags are set in the ap-options
447
field of the AP_REQ message.
449
The protocol is complete in the KRB_ERROR case (from the server
450
perspective, but the client should retry depending on the error
451
type). If the IAKERB proxy receives an AS_REP message from the KDC,
452
the IAKERB proxy will then obtain the client's TGT from the AS_REP
453
message. The IAKERB proxy then sends a TGS_REQ message with the
454
client's TGT in the additional tickets field to the client's KDC
455
(ENC-TKT-IN-SKEY option).
457
The IAKERB proxy MAY handle returned KRB_ERROR messages and retry the
458
TGS request message (e.g. on a KRB_ERR_RESPONSE_TOO_BIG error,
459
switching to TCP from UDP). Ultimately, the IAKERB proxy either
460
proxies a KRB_ERROR message to the client (after adding the GSS
461
framing), sends one of the new GSS framed KRB_ERROR messages defined
462
above, or it receives the TGS_REP message from the KDC and then
463
creates the AP_REQ message according to RFC 1964 [2]. The IAKERB
464
proxy then sends a GSS token containing the AS_REP message with the
465
AP_REQ message in the padata field as described above. (Note:
466
although the server sends the context token with the AP_REQ, the
467
client is the initiator.) The IAKERB proxy MUST set both the mutual-
468
required and use-session-key flags in the AP_REQ message in order to
469
cause the client to authenticate as well. The authenticator SHOULD
470
include the subsession key (containing locally added entropy). The
471
client will reply with the GSSAPI enscapsulated AP_REP message, if
472
the IAKERB proxy's authentication succeeds (which SHOULD include the
473
subkey field to facilitate use with other key derivation algorithms
474
outside of [2]). If all goes well, then, in order to enable
475
subsequent efficient client authentications, the IAKERB proxy will
476
then send a final message of type KRB_TKT_PUSH containing a Kerberos
477
ticket (the reverse ticket) that has the IAKERB client principal
478
identifier in the client identifier field of the ticket and its own
479
principal identity in the server identifier field of the ticket (see
482
KRB_TKT_PUSH :: = [APPLICATION 17] SEQUENCE {
483
pvno[0] INTEGER, -- 5 (protocol version)
484
msg-type[1] INTEGER, -- 17 (message type)
488
NOTE: The KRB_TKT_PUSH message must be encoded using ASN.1 DER. The
489
key used to encrypt the reverse ticket is a long term secret key
490
chosen by the IAKERB proxy. The fields are identical to the AP_REQ
491
ticket, except the client name will be switched with the server name,
492
and the server realm will be switched with the client realm. (The one
493
other exception is that addresses should not be copied from the
494
AP_REQ ticket to the reverse ticket). Sending the reverse ticket
498
Trostle, Swift, Aboba, Zorn [Page 8]
500
INTERNET DRAFT October 2002 Expires March 2003
503
allows the client to efficiently initiate subsequent reauthentication
504
attempts with a RFC1964 AP_REQ message. Note that the TKT_PUSH
505
message is sent after mutual authentication and key establishment are
509
Client --------> IAKERB proxy --------------------> KDC
512
Client IAKERB proxy <-------------------- KDC
515
Client IAKERB proxy --------------------> KDC
517
TGT as additional TGT
519
Client IAKERB proxy <-------------------- KDC
523
Client <-------- IAKERB proxy KDC
524
AS_REP w/ AP_REQ in padata field
526
Client --------> IAKERB proxy KDC
529
-------------------------------------------------------------
530
post-key establishment and application data flow phase:
532
Client <-------- IAKERB proxy KDC
533
TKT_PUSH (w/ticket targetted at IAKERB proxy
534
to enable fast subsequent authentication)
537
Figure 3: IAKERB Minimal Messages Option: AS case
541
(b) TGS_REQ case: (used when the client has a TGT)
543
The client indicates that the minimal messages sub-protocol will be
544
used by using the appropriate OID as described above. The client
545
initially sends a KRB_TKT_PUSH message (with the GSS header) to the
546
IAKERB proxy in order to send it a TGT. The IAKERB proxy will obtain
547
the client's TGT from the KRB_TKT_PUSH message and then proceed to
548
send a TGS_REQ message to a KDC where the realm of the KDC is equal
549
to the realm from the server realm field in the TGT sent by the
550
client in the KRB_TKT_PUSH message. NOTE: this realm could be the
551
client's home realm, the proxy's realm, or an intermediate realm. The
552
protocol then continues as in the minimal messages AS_REQ case
553
described above (see Figure 2); the IAKERB proxy's TGS_REQ message
554
contains the client's TGT in the additional tickets field (ENC-TKT-
555
IN-SKEY option). The IAKERB proxy then receives the TGS_REP message
556
from the KDC and then sends a RFC 1964 AP_REQ message to the client
560
Trostle, Swift, Aboba, Zorn [Page 9]
562
INTERNET DRAFT October 2002 Expires March 2003
565
(with the MUTUAL AUTH flag set - see AS_REQ case).
567
To summarize, here are the steps for the minimal messages TGS
571
(has TGT already for, or targetted at, realm X.ORG)
572
sends TKT_PUSH message to server containing client's ticket
573
for X.ORG (which could be a crossrealm TGT)
576
(has TGT already targetted at realm X.ORG)
577
sends to KDC (where KDC has principal id = server name,
578
server realm from client ticket) a TGS_REQ:
579
TGT in TGS_REQ is server's TGT
580
Additional ticket in TGS_REQ is client's TGT from TKT_PUSH
582
Server name in TGS_REQ (optional by rfc1510) is not present
583
Server realm in TGS_REQ is realm in server's TGT - X.ORG
587
Server name = client's name
588
Client name = server's name, Client realm = server's realm
589
Server realm = client's realm
590
Encrypted with: session key from client's TGT (passed in
591
additional tickets field)
593
Encrypted with session key from server's TGT
594
Sends TGS_REP and ticket to server
597
Decrypts TGS_REP from KDC using session key from its TGT
599
Ticket = ticket from KDC (which was encrypted with
600
client's TGT session key)
601
authenticator clientname = server's name (matches
602
clientname in AP-REQ ticket)
603
authenticator clientrealm = server's realm
604
subsession key in authenticator is present (same
605
etype as the etype of the session key in the ticket)
606
checksum in authenticator is the RFC 1964 checksum
607
sequence number in authenticator is present (RFC 1964)
608
ap-options has both use-session-key and mutual-required
610
Sends AP_REQ (with GSS-API framing) to client
614
Decrypts ticket using session key from its TGT
616
Builds AP_REP and sends to server (AP_REP SHOULD include
617
subkey field to facilitate use with other key derivation
618
algorithms outside of [2] e.g., [8] and its successors.
622
Trostle, Swift, Aboba, Zorn [Page 10]
624
INTERNET DRAFT October 2002 Expires March 2003
627
Some apps may have their own message protection key
628
derivation algorithm and protected message format.
629
AP_REP includes the sequence number per RFC 1964.)
632
Verifies AP-REP. Builds reverse ticket as described above
633
and sends reverse ticket to client using the KRB_TKT_PUSH
634
message. The reverse ticket is the same as the AP_REQ
635
ticket except the client name, realm are switched with the
636
server name, realm fields and it is encrypted in a secret
637
key known to the IAKERB proxy.
639
8. Addresses in Tickets
641
In IAKERB, the machine sending requests to the KDC is the server and
642
not the client. As a result, the client should not include its
643
addresses in any KDC requests for two reasons. First, the KDC may
644
reject the forwarded request as being from the wrong client. Second,
645
in the case of initial authentication for a dial-up client, the
646
client machine may not yet possess a network address. Hence, as
647
allowed by RFC1510 [1], the addresses field of the AS and TGS
648
requests SHOULD be blank and the caddr field of the ticket SHOULD
649
similarly be left blank.
651
9. Security Considerations
653
Similar to other network access protocols, IAKERB allows an
654
unauthenticated client (possibly outside the security perimeter of an
655
organization) to send messages that are proxied to interior servers.
656
When combined with DNS SRV RR's for KDC lookup, there is the
657
possibility that an attacker can send an arbitrary message to an
658
interior server. There are several aspects to note here:
660
(1) in many scenarios, compromise of the DNS lookup will require the
661
attacker to already have access to the internal network. Thus the
662
attacker would already be able to send arbitrary messages to interior
663
servers. No new vulnerabilities are added in these scenarios.
665
(2) in a scenario where DNS SRV RR's are being used to locate the
666
KDC, IAKERB is being used, and an external attacker can modify DNS
667
responses to the IAKERB proxy, there are several countermeasures to
668
prevent arbitrary messages from being sent to internal servers:
670
(a) KDC port numbers can be statically configured on the IAKERB
671
proxy. In this case, the messages will always be sent to KDC's. For
672
an organization that runs KDC's on a static port (usually port 88)
673
and does not run any other servers on the same port, this
674
countermeasure would be easy to administer and should be effective.
676
(b) the proxy can do application level sanity checking and filtering.
677
This countermeasure should eliminate many of the above attacks.
679
(c) DNS security can be deployed. This countermeasure is probably
680
overkill for this particular problem, but if an organization has
684
Trostle, Swift, Aboba, Zorn [Page 11]
686
INTERNET DRAFT October 2002 Expires March 2003
689
already deployed DNS security for other reasons, then it might make
690
sense to leverage it here. Note that Kerberos could be used to
691
protect the DNS exchanges. The initial DNS SRV KDC lookup by the
692
proxy will be unprotected, but an attack here is at most a denial of
693
service (the initial lookup will be for the proxy's KDC to facilitate
694
Kerberos protection of subsequent DNS exchanges between itself and
697
In the minimal messages protocol option, the application server sends
698
an AP_REQ message to the client. The ticket in the AP_REQ message
699
SHOULD NOT contain authorization data since some operating systems
700
may allow the client to impersonate the server and increase its own
701
privileges. If the ticket from the server connotes any authorization,
702
then the minimal messages protocol should not be used. Also, the
703
minimal messages protocol may facilitate denial of service attacks in
704
some environments; to prevent these attacks, it may make sense for
705
the minimal messages protocol server to only accept a KRB_TGT_PUSH
706
message on a local network interface (to ensure that the message was
707
not sent from a remote malicious host).
711
We thank the Kerberos Working Group chair, Doug Engert, for his
712
efforts in helping to progress this specification. We also thank Ken
713
Raeburn for his comments and the other working group participants for
718
[1] J. Kohl, C. Neuman, "The Kerberos Network Authentication
719
Service (V5)", RFC 1510.
721
[2] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964.
723
[3] J. Linn, "Generic Security Service Application Program
724
Interface Version 2, Update 1", RFC 2743.
726
[4] D. Davis, R. Swick, "Workstation Services and Kerberos
727
Authentication at Project Athena", Technical Memorandum TM-424,
728
MIT Laboratory for Computer Science, February 1990.
730
[5] S. Bradner, "The Internet Standards Process -- Revision 3", BCP
731
9, RFC 2026, October 1996.
733
[6] S. Bradner, "Key words for use in RFCs to Indicate Requirement
734
Levels", BCP 14, RFC 2119, March 1997.
736
[7] E. Baize, D. Pinkas, "The Simple and Protected GSS-API Negotiation
737
Mechanism," RFC 2478, December 1998.
739
[8] Part 11: Wireless LAN Medium Access Control (MAC) and Physical
740
Layer (PHY) Specifications, ANSI/IEEE Std. 802.11, 1999 Edition.
746
Trostle, Swift, Aboba, Zorn [Page 12]
748
INTERNET DRAFT October 2002 Expires March 2003
751
12. Author's Addresses
756
San Jose, CA 95134, U.S.A.
757
Email: jtrostle@cisco.com
758
Phone: (408) 527-6201
761
University of Washington
763
Email: mikesw@cs.washington.edu
768
Redmond, Washington, 98052, U.S.A.
769
Email: bernarda@microsoft.com
770
Phone: (425) 706-6605
776
Phone: (425) 468-0955
778
This draft expires on March 31st, 2003.
808
Trostle, Swift, Aboba, Zorn [Page 13]
added
removed
doc/standardisation/draft-ietf-cat-iakerb-09.txt
