4
Kerberos Working Group S. Hartman
6
Expires: April 24, 2005 October 24, 2004
9
A Generalized Framework for Kerberos Pre-Authentication
10
draft-ietf-krb-wg-preauth-framework-02
14
This document is an Internet-Draft and is subject to all provisions
15
of section 3 of RFC 3667. By submitting this Internet-Draft, each
16
author represents that any applicable patent or other IPR claims of
17
which he or she is aware have been or will be disclosed, and any of
18
which he or she become aware will be disclosed, in accordance with
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
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 April 24, 2005.
41
Copyright (C) The Internet Society (2004).
45
Kerberos is a protocol for verifying the identity of principals
46
(e.g., a workstation user or a network server) on an open network.
47
The Kerberos protocol provides a mechanism called pre-authentication
48
for proving the identity of a principal and for better protecting
49
the long-term secret of the principal.
51
This document describes a model for Kerberos pre-authentication
52
mechanisms. The model describes what state in the Kerberos request a
56
Hartman Expires April 24, 2005 [Page 1]
58
Internet-Draft Kerberos Preauth Framework October 2004
61
pre-authentication mechanism is likely to change. It also describes
62
how multiple pre-authentication mechanisms used in the same request
65
This document also provides common tools needed by multiple
66
pre-authentication mechanisms.
68
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
69
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
70
document are to be interpreted as described in [1].
74
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
75
2. Model for Pre-Authentication . . . . . . . . . . . . . . . . . 4
76
2.1 Information Managed by Model . . . . . . . . . . . . . . . 5
77
2.2 The Initial Preauth_Required Error . . . . . . . . . . . . 7
78
2.3 Client to KDC . . . . . . . . . . . . . . . . . . . . . . 8
79
2.4 KDC to Client . . . . . . . . . . . . . . . . . . . . . . 8
80
3. Pre-Authentication Facilities . . . . . . . . . . . . . . . . 10
81
3.1 Client Authentication . . . . . . . . . . . . . . . . . . 11
82
3.2 Strengthen Reply Key . . . . . . . . . . . . . . . . . . . 11
83
3.3 Replace Reply Key . . . . . . . . . . . . . . . . . . . . 12
84
3.4 Verify Response . . . . . . . . . . . . . . . . . . . . . 12
85
4. Requirements for Pre-Authentication Mechanisms . . . . . . . . 14
86
5. Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 15
87
5.1 Combine Keys . . . . . . . . . . . . . . . . . . . . . . . 15
88
5.2 Signing Requests/Responses . . . . . . . . . . . . . . . . 15
89
5.3 Managing State for the KDC . . . . . . . . . . . . . . . . 15
90
5.4 PA-AUTHENTICATION-SET . . . . . . . . . . . . . . . . . . 15
91
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
92
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
93
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
94
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
95
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
96
9.2 Informative References . . . . . . . . . . . . . . . . . . . 19
97
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
98
A. Todo List . . . . . . . . . . . . . . . . . . . . . . . . . . 20
99
Intellectual Property and Copyright Statements . . . . . . . . 21
112
Hartman Expires April 24, 2005 [Page 2]
114
Internet-Draft Kerberos Preauth Framework October 2004
119
The core Kerberos specification treats pre-authentication data as an
120
opaque typed hole in the messages to the KDC that may influence the
121
reply key used to encrypt the KDC response. This generality has been
122
useful: pre-authentication data is used for a variety of extensions
123
to the protocol, many outside the expectations of the initial
124
designers. However, this generality makes designing the more common
125
types of pre-authentication mechanisms difficult. Each mechanism
126
needs to specify how it interacts with other mechanisms. Also,
127
problems like combining a key with the long-term secret or proving
128
the identity of the user are common to multiple mechanisms. Where
129
there are generally well-accepted solutions to these problems, it is
130
desirable to standardize one of these solutions so mechanisms can
131
avoid duplication of work. In other cases, a modular approach to
132
these problems is appropriate. The modular approach will allow new
133
and better solutions to common pre-authentication problems to be used
134
by existing mechanisms as they are developed.
136
This document specifies a framework for Kerberos pre-authentication
137
mechanisms. IT defines the common set of functions
138
pre-authentication mechanisms perform as well as how these functions
139
affect the state of the request and response. In addition several
140
common tools needed by pre-authentication mechanisms are provided.
141
Unlike [3], this framework is not complete--it does not describe all
142
the inputs and outputs for the pre-authentication mechanisms.
143
Mechanism designers should try to be consistent with this framework
144
because doing so will make their mechanisms easier to implement.
145
Kerberos implementations are likely to have plugin architectures for
146
pre-authentication; such architectures are likely to support
147
mechanisms that follow this framework plus commonly used extensions.
149
This document should be read only after reading the documents
150
describing the Kerberos cryptography framework [3] and the core
151
Kerberos protocol [2]. This document freely uses terminology and
152
notation from these documents without reference or further
168
Hartman Expires April 24, 2005 [Page 3]
170
Internet-Draft Kerberos Preauth Framework October 2004
173
2. Model for Pre-Authentication
175
when a Kerberos client wishes to obtain a ticket using the
176
authentication server, it sends an initial AS request. If
177
pre-authentication is being used, then the KDC will respond with a
178
KDC_ERR_PREAUTH_REQUIRED error. Alternatively, if the client knows
179
what pre-authentication to use, it MAY optimize a round-trip and send
180
an initial request with padata included. If the client includes the
181
wrong padata, the server MAY return KDC_ERR_PREAUTH_FAILED with no
182
indication of what padata should have been included. For
183
interoperability reasons, clients that include optimistic
184
pre-authentication MUST retry with no padata and examine the
185
KDC_ERR_PREAUTH_REQUIRED if they receive a KDC_ERR_PREAUTH_FAILED in
186
response to their initial optimistic request.
188
The KDC maintains no state between two requests; subsequent requests
189
may even be processed by a different KDC. On the other hand, the
190
client treats a series of exchanges with KDCs as a single
191
authentication session. Each exchange accumulates state and
192
hopefully brings the client closer to a successful authentication.
194
These models for state management are in apparent conflict. For many
195
of the simpler pre-authentication scenarios, the client uses one
196
round trip to find out what mechanisms the KDC supports. Then the
197
next request contains sufficient pre-authentication for the KDC to be
198
able to return a successful response. For these simple scenarios,
199
the client only sends one request with pre-authentication data and so
200
the authentication session is trivial. For more complex
201
authentication sessions, the KDC needs to provide the client with a
202
cookie to include in future requests to capture the current state of
203
the authentication session. Handling of multiple round-trip
204
mechanisms is discussed in Section 5.3.
206
This framework specifies the behavior of Kerberos pre-authentication
207
mechanisms used to identify users or to modify the reply key used to
208
encrypt the KDC response. The padata typed hole may be used to carry
209
extensions to Kerberos that have nothing to do with proving the
210
identity of the user or establishing a reply key. These extensions
211
are outside the scope of this framework. However mechanisms that do
212
accomplish these goals should follow this framework.
214
This framework specifies the minimum state that a Kerberos
215
implementation needs to maintain while handling a request in order to
216
process pre-authentication. It also specifies how Kerberos
217
implementations process the pre-authentication data at each step of
218
the AS request process.
224
Hartman Expires April 24, 2005 [Page 4]
226
Internet-Draft Kerberos Preauth Framework October 2004
229
2.1 Information Managed by Model
231
The following information is maintained by the client and KDC as each
232
request is being processed:
233
o The reply key used to encrypt the KDC response
234
o How strongly the identity of the client has been authenticated
235
o Whether the reply key has been used in this authentication session
236
o Whether the reply key has been replaced in this authentication
238
o Whether the contents of the KDC response can be verified by the
240
o Whether the contents of the KDC response can be verified by the
243
Conceptually, the reply key is initially the long-term key of the
244
principal. However, principals can have multiple long-term keys
245
because of support for multiple encryption types, salts and
246
string2key parameters. As described in section 5.2.7.5 of the
247
Kerberos protocol [2], the KDC sends PA-ETYPe-INFO2 to notify the
248
client what types of keys are available. Thus in full generality,
249
the reply key in the pre-authentication model is actually a set of
250
keys. At the beginning of a request, it is initialized to the set of
251
long-term keys advertised in the PA-ETYPE-INFO2 element on the KDC.
252
If multiple reply keys are available, the client chooses which one to
253
use. Thus the client does not need to treat the reply key as a set.
254
At the beginning of a handling a request, the client picks a reply
257
KDC implementations MAY choose to offer only one key in the
258
PA-ETYPE-INFO2 element. Since the KDC already knows the client's
259
list of supported enctypes from the request, no interoperability
260
problems are created by choosing a single possible reply key. This
261
way, the KDC implementation avoids the complexity of treating the
264
At the beginning of handling a message on both the client and KDC,
265
the client's identity is not authenticated. A mechanism may indicate
266
that it has successfully authenticated the client's identity. This
267
information is useful to keep track of on the client in order to
268
know what pre-authentication mechanisms should be used. The KDC
269
needs to keep track of whether the client is authenticated because
270
the primary purpose of pre-authentication is to authenticate the
271
client identity before issuing a ticket. Implementations that have
272
pre-authentication mechanisms offering significantly different
273
strengths of client authentication MAY choose to keep track of the
274
strength of the authentication used as an input into policy
275
decisions. For example, some principals might require strong
276
pre-authentication, while less sensitive principals can use
280
Hartman Expires April 24, 2005 [Page 5]
282
Internet-Draft Kerberos Preauth Framework October 2004
285
relatively weak forms of pre-authentication like encrypted timestamp.
287
Initially the reply key has not been used. A pre-authentication
288
mechanism that uses the reply key either directly to encrypt or
289
checksum some data or indirectly in the generation of new keys MUST
290
indicate that the reply key is used. This state is maintained by the
291
client and KDC to enforce the security requirement stated in Section
292
3.3 that the reply key cannot be replaced after it is used.
294
Initially the reply key has not been replaced. If a mechanism
295
implements the Replace Reply Key facility discussed in Section 3.3,
296
then the state MUST be updated to indicate that the reply key has
297
been replaced. Once the reply key has been replaced, knowledge of
298
the reply key is insufficient to authenticate the client. The reply
299
key is marked replaced in exactly the same situations as the KDC
300
reply is marked as not being verified to the client principal.
301
However, while mechanisms can verify the KDC request to the client,
302
once the reply key is replaced, then the reply key remains replaced
303
for the remainder of the authentication session.
305
Without pre-authentication, the client knows that the KDC request is
306
authentic and has not been modified because it is encrypted in the
307
long-term key of the client. Only the KDC and client know that key.
308
So at the start of handling any message the KDC request is presumed
309
to be verified to the client principal. Any pre-authentication
310
mechanism that sets a new reply key not based on the principal's
311
long-term secret MUST either verify the KDC response some other way
312
or indicate that the response is not verified. If a mechanism
313
indicates that the response is not verified then the client
314
implementation MUST return an error unless a subsequent mechanism
315
verifies the response. The KDC needs to track this state so it can
316
avoid generating a response that is not verified.
318
The typical Kerberos request does not provide a way for the client
319
machine to know that it is talking to the correct KDC. Someone who
320
can inject packets into the network between the client machine and
321
the KDC and who knows the password that the user will give to the
322
client machine can generate a KDC response that will decrypt
323
properly. So, if the client machine needs to authenticate that the
324
user is in fact the named principal, then the client machine needs to
325
do a TGS request for itself as a service. Some pre-authentication
326
mechanisms may provide a way for the client to authenticate the KDC.
327
Examples of this include signing the response with a well-known
328
public key or providing a ticket for the client machine as a service
329
in addition to the requested ticket.
336
Hartman Expires April 24, 2005 [Page 6]
338
Internet-Draft Kerberos Preauth Framework October 2004
341
2.2 The Initial Preauth_Required Error
343
Typically a client starts an authentication session by sending an
344
initial request with no pre-authentication. If the KDC requires
345
pre-authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED
346
message. This message MAY also be returned for pre-authentication
347
configurations that use multi-round-trip mechanisms; see Section 2.4
348
for details of that case. This
350
The KDC needs to choose which mechanisms to offer the client. The
351
client needs to be able to choose what mechanisms to use from the
352
first message. For example consider the KDC that will accept
353
mechanism A followed by mechanism B or alternatively the single
354
mechanism C. A client that supports A and C needs to know that it
355
should not bother trying A.
357
Mechanisms can either be sufficient on their own or can be part of an
358
authentication set--a group of mechanisms that all need to
359
successfully complete in order to authenticate a client. Some
360
mechanisms may only be useful in authentication sets; others may be
361
useful alone or in authentication sets. For the second group of
362
mechanisms, KDC policy dictates whether the mechanism will be part of
363
an authentication set or offered alone. For each mechanism that is
364
offered alone, the KDC includes the pre-authentication type ID of the
365
mechanism in the padata sequence returned in the
366
KDC_ERR_PREAUTH_REQUIRED error. The KDC MAY include any initial
367
data for the mechanisms.
369
The KDC includes a a PA-AUTHENTICATION-SET padata element for each
370
authentication set; this element is defined in Section 5.4. This
371
element includes the pa-type and pa-value for the first mechanism in
372
the authentication set. It also includes the pa-type for each of
373
the other mechanisms. Associated with the second and following
374
pa-type is a pa-hint, which is an octet-string specified by the
375
pre-authentication mechanism. This hint may provide information for
376
the client which helps it determine whether the mechanism can be
377
used. For example a public-key mechanism might include the
378
certificate authorities it trusts in the hint info. Most mechanisms
379
today do not specify hint info; if a mechanism does not specify hint
380
info the KDC MUST not send a hint for that mechanism. To allow
381
future revisions of mechanism specifications to add hint info,
382
clients MUST ignore hint info received for mechanisms that the client
383
believes do not support hint info.
385
The KDC SHOULD NOT send data that is encrypted in the long-term
386
password-based key of the principal. Doing so has the same security
387
exposures as the Kerberos protocol without pre-authentication. There
388
are few situations where pre-authentication is desirable and where
392
Hartman Expires April 24, 2005 [Page 7]
394
Internet-Draft Kerberos Preauth Framework October 2004
397
the KDC needs to expose ciphertext encrypted in a weak key before the
398
client has proven knowledge of that key.
402
This description assumes a client has already received a
403
KDC_ERR_PREAUTH_REQUIRED from the KDC. If the client performs
404
optimistic pre-authentication then the client needs to optimisticly
405
choose the information it would normally receive from that error
408
The client starts by initializing the pre-authentication state as
409
specified. It then processes the padata in the
410
KDC_ERR_PREAUTH_REQUIRED.
412
When processing the response to the first KDC_ERR_PREAUTH_REQUIRED,
413
the client MAY ignore any padata it chooses unless doing so violates
414
a specification to which the client conforms. Clients MUST NOT
415
ignore the padata defined in Section 5.3. Clients SHOULD process
416
padata unrelated to this framework or other means of authenticating
417
the user. Clients SHOULD choose one authentication set or mechanism
418
that could lead to authenticating the user and ignore the rest.
419
Since the set of mechanisms offered by the KDC is ordered, clients
420
typically choose the first mechanism that the client can usefully
421
perform. If a client chooses to ignore a padata it MUST NOT process
422
the padata, allow the padata to affect the pre-authentication state,
423
nor respond to the padata.
425
For each padata the client chooses to process, the client processes
426
the padata and modifies the pre-authentication state as required by
427
that mechanism. Padata are processed in the order received from the
430
After processing the padata in the KDC error, the client generates a
431
new request. It processes the pre-authentication mechanisms in the
432
order in which they will appear in the next request, updating the
433
state as appropriate. When the request is complete it is sent.
437
When a KDC receives an AS request from a client, it needs to
438
determine whether it will respond with an error or a AS reply.
439
There are many causes for an error to be generated that have nothing
440
to do with pre-authentication; they are discussed in the Kerberos
443
From the standpoint of evaluating the pre-authentication, the KDC
444
first starts by initializing the pre-authentication state. IT then
448
Hartman Expires April 24, 2005 [Page 8]
450
Internet-Draft Kerberos Preauth Framework October 2004
453
processes the padata in the request. AS mentioned in Section 2.2,
454
the KDC MAY ignore padata that is inappropriate for the configuration
455
and MUST ignore padata of an unknown type.
457
At this point the KDC decides whether it will issue a
458
pre-authentication required error or a reply. Typically a KDC will
459
issue a reply if the client's identity has been authenticated to a
462
In the case of a PREAUTH_REQUIRED error, the KDC first starts by
463
initializing the pre-authentication state. Then it processes any
464
padata in the client's request in the order provided by the client.
465
Mechanisms that are not understood by the KDC are ignored.
466
Mechanisms that are inappropriate for the client principal or request
467
SHOULD also be ignored. Next, it generates padata for the error
468
response, modifying the pre-authentication state appropriately as
469
each mechanism is processed. The KDC chooses the order in which it
470
will generated padata (and thus the order of padata in the response),
471
but it needs to modify the pre-authentication state consistently with
472
the choice of order. For example, if some mechanism establishes an
473
authenticated client identity, then the mechanisms subsequent in the
474
generated response receive this state as input. After the padata is
475
generated, the error response is sent. Typically the second and
476
following PREAUTH_REQUIRED errors in an authentication session will
477
include KDC state as discussed in Section 5.3.
479
To generate a final reply, the KDC generates the padata modifying the
480
pre-authentication state as necessary. Then it generates the final
481
response, encrypting it in the current pre-authentication reply key.
504
Hartman Expires April 24, 2005 [Page 9]
506
Internet-Draft Kerberos Preauth Framework October 2004
509
3. Pre-Authentication Facilities
511
Pre-Authentication mechanisms can be thought of as providing various
512
conceptual facilities. This serves two useful purposes. First,
513
mechanism authors can choose only to solve one specific small
514
problem. It is often useful for a mechanism designed to offer key
515
management not to directly provide client authentication but instead
516
to allow one or more other mechanisms to handle this need. Secondly,
517
thinking about the abstract services that a 2mechanism provides
518
yields a minimum set of security requirements that all mechanisms
519
providing that facility must meet. These security requirements are
520
not complete; mechanisms will have additional security requirements
521
based on the specific protocol they employ.
523
A mechanism is not constrained to only offering one of these
524
facilities. While such mechanisms can be designed and are sometimes
525
useful, many pre-authentication mechanisms implement several
526
facilities. By combining multiple facilities in a single mechanism,
527
it is often easier to construct a secure, simple solution than by
528
solving the problem in full generality. Even when mechanisms provide
529
multiple facilities, they need to meet the security requirements for
530
all the facilities they provide.
532
According to Kerberos extensibility rules (section 1.4.2 of the
533
Kerberos specification [2]), an extension MUST NOT change the
534
semantics of a message unless a recipient is known to understand that
535
extension. Because a client does not know that the KDC supports a
536
particular pre-authentication mechanism when it sends an initial
537
request, a preauth mechanism MUST NOT change the semantics of the
538
request in a way that will break a KDC that does not understand that
539
mechanism. Similarly, KDCs MUST not send messages to clients that
540
affect the core semantics unless the clients have indicated support
543
The only state in this model that would break the interpretation of a
544
message is changing the expected reply key. If one mechanism changed
545
the reply key and a later mechanism used that reply key, then a KDC
546
that interpreted the second mechanism but not the first would fail to
547
interpret the request correctly. In order to avoid this problem,
548
extensions that change core semantics are typically divided into two
549
parts. The first part proposes a change to the core semantic--for
550
example proposes a new reply key. The second part acknowledges that
551
the extension is understood and that the change takes effect.
552
Section 3.2 discusses how to design mechanisms that modify the reply
553
key to be split into a proposal and acceptance without requiring
554
additional round trips to use the new reply key in subsequent
555
pre-authentication. Other changes in the state described in Section
556
2.1 can safely be ignored by a KDC that does not understand a
560
Hartman Expires April 24, 2005 [Page 10]
562
Internet-Draft Kerberos Preauth Framework October 2004
565
mechanism. Mechanisms that modify the behavior of the request
566
outside the scope of this framework need to carefully consider the
567
Kerberos extensibility rules to avoid similar problems.
569
3.1 Client Authentication
571
The client authentication facility proves the identity of a user to
572
the KDC before a ticket is issued. Examples of mechanisms
573
implementing this facility include the encrypted timestamp facility
574
defined in Section 5.2.7.2 of the Kerberos specification [2] and the
575
single-use mechanism defined in [5]. Mechanisms that provide this
576
facility are expected to mark the client as authenticated.
578
Mechanisms implementing this facility SHOULD require the client to
579
prove knowledge of the reply key before transmitting a successful
580
KDC reply. Otherwise, an attacker can intercept the
581
pre-authentication exchange and get a reply to attack. One way of
582
proving the client knows the reply key is to implement the Replace
583
Reply Key facility along with this facility. The Pkinit mechanism
584
[6] implements Client Authentication along side Replace Reply Key.
586
If the reply key has been replaced, then mechanisms such as encrypted
587
timestamp that rely on knowledge of the reply key to authenticate the
588
client MUST NOT be used.
590
3.2 Strengthen Reply Key
592
Particularly, when dealing with keys based on passwords, it is
593
desirable to increase the strength of the key by adding additional
594
secrets to it. Examples of sources of additional secrets include the
595
results of a Diffie-Hellman key exchange or key bits from the output
596
of a smart card [5]. Typically these additional secrets are
597
converted into a Kerberos protocol key. Then they are combined with
598
the existing reply key as discussed in Section 5.1.
600
If a mechanism implementing this facility wishes to modify the reply
601
key before knowing that the other party in the exchange supports the
602
mechanism, it proposes modifying the reply key. The other party then
603
includes a message indicating that the proposal is accepted if it is
604
understood and meets policy. In many cases it is desirable to use
605
the new reply key for client authentication and for other facilities.
606
Waiting for the other party to accept the proposal and actually
607
modify the reply key state would add an additional round trip to the
608
exchange. Instead, mechanism designers are encouraged to include a
609
typed hole for additional padata in the message that proposes the
610
reply key change. The padata included in the typed hole are
611
generated assuming the new reply key. If the other party accepts the
612
proposal, then these padata are interpreted as if they were included
616
Hartman Expires April 24, 2005 [Page 11]
618
Internet-Draft Kerberos Preauth Framework October 2004
621
immediately following the proposal. The party generating the
622
proposal can determine whether the padata were processed based on
623
whether the proposal for the reply key is accepted.
625
The specific formats of the proposal message, including where padata
626
are are included is a matter for the mechanism specification.
627
Similarly, the format of the message accepting the proposal is
630
Mechanisms implementing this facility and including a typed hole for
631
additional padata MUST checksum that padata using a keyed checksum or
632
encrypt the padata. Typically the reply key is used to protect the
633
padata. XXX If you are only minimally increasing the strength of the
634
reply key, this may give the attacker access to something too close
635
to the original reply key. However, binding the padata to the new
636
reply key seems potentially important from a security standpoint.
637
There may also be objections to this from a double encryption
638
standpoint because we also recommend client authentication facilities
639
be tied to the reply key.
641
3.3 Replace Reply Key
643
The Replace Reply Key facility replaces the key in which a successful
644
AS reply will be encrypted. This facility can only be used in cases
645
where knowledge of the reply key is not used to authenticate the
646
client. The new reply key MUST be communicated to the client and KDC
647
in a secure manner. Mechanisms implementing this facility MUST mark
648
the reply key as replaced in the pre-authentication state.
649
Mechanisms implementing this facility MUST either provide a mechanism
650
to verify the KDC reply to the client or mark the reply as unverified
651
in the pre-authentication state. Mechanisms implementing this
652
facility SHOULD NOT be used if a previous mechanism has used the
655
As with the Strengthen Reply Key facility, Kerberos extensibility
656
rules require that the reply key not be changed unless both sides of
657
the exchange understand the extension. In the case of this facility
658
it will likely be more common for both sides to know that the
659
facility is available by the time that the new key is available to be
660
used. However, mechanism designers can use a container for padata in
661
a proposal message as discussed in Section 3.2 if appropriate.
665
This facility verifies that the response comes from the expected KDC.
666
In traditional Kerberos, the KDC and the client share a key, so if
667
the ticket can be decrypted then the client knows that a trusted KDC
668
responded. Note that the client machine cannot trust the client
672
Hartman Expires April 24, 2005 [Page 12]
674
Internet-Draft Kerberos Preauth Framework October 2004
677
unless the machine retrieves a service ticket for itself. However,
678
if the reply key is replaced, some mechanism is required to verify
679
the KDC. Mechanisms providing this facility provide such a
680
mechanism. They mark the pre-authentication state as having been
681
verified; they may also mark it as verified to the client host.
728
Hartman Expires April 24, 2005 [Page 13]
730
Internet-Draft Kerberos Preauth Framework October 2004
733
4. Requirements for Pre-Authentication Mechanisms
735
This section lists requirements for specifications of
736
pre-authentication mechanisms.
738
For each message in the pre-authentication mechanism, the
739
specification describes the pa-type value to be used and the
740
contents of the message. The processing of the message my the
741
sender and recipient is also specified. This specification needs to
742
include all modifications to the pre-authentication state.
744
Generally mechanisms have a message that can be sent as part of the
745
first KDC_ERR_PREAUTH_REQUIRED or as part of an authentication set.
746
If the client will need information such as available certificate
747
authorities in order to determine if it can use the mechanism, then
748
this information should be in that first message. IN addition, such
749
mechanisms should also define a pa-hint to be included in
750
authentication sets when the mechanism is not the first mechanism in
751
the authentication set. Often, the same information included in the
752
first pa-value is appropriate to include in the pa-hint.
754
In order to ease in security analysis the mechanism specification
755
should describe what facilities from this document are offered by the
756
mechanism. For each facility, the security considerations section of
757
the mechanism specification should show that the security
758
requirements of that facility are met.
760
Significant problems have resulted in the specification of Kerberos
761
protocols because much of the KDC exchange is not protected against
762
authentication. The security considerations section should discuss
763
unauthenticated plaintext attacks. It should either show that
764
plaintext is protected or discuss what harm an attacker could do by
765
modifying the plaintext. It is generally acceptable for an attacker
766
to be able to cause the protocol negotiation to fail by modifying
767
plaintext. More significant attacks should be evaluated carefully.
784
Hartman Expires April 24, 2005 [Page 14]
786
Internet-Draft Kerberos Preauth Framework October 2004
789
5. Tools for Use in Pre-Authentication Mechanisms
793
5.2 Signing Requests/Responses
795
5.3 Managing State for the KDC
797
5.4 PA-AUTHENTICATION-SET
840
Hartman Expires April 24, 2005 [Page 15]
842
Internet-Draft Kerberos Preauth Framework October 2004
845
6. IANA Considerations
896
Hartman Expires April 24, 2005 [Page 16]
898
Internet-Draft Kerberos Preauth Framework October 2004
901
7. Security Considerations
903
Very little of the AS request is authenticated. Same for padata
904
in the reply or error. Discuss implications
905
Table of security requirements stated elsewhere in the document
952
Hartman Expires April 24, 2005 [Page 17]
954
Internet-Draft Kerberos Preauth Framework October 2004
1008
Hartman Expires April 24, 2005 [Page 18]
1010
Internet-Draft Kerberos Preauth Framework October 2004
1015
9.1 Normative References
1017
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1018
Levels", RFC 2119, BCP 14, March 1997.
1020
[2] Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos
1021
Network Authentication Service (V5)",
1022
draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in
1023
progress), June 2004.
1025
[3] Raeburn, K., "Encryption and Checksum Specifications for
1026
Kerberos 5", draft-ietf-krb-wg-crypto-03.txt (work in progress).
1028
[4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
1031
9.2 Informative References
1033
[5] Hornstein, K., Renard, K., Neuman, C. and G. Zorn, "Integrating
1034
Single-use Authentication Mechanisms with Kerberos",
1035
draft-ietf-krb-wg-kerberos-sam-02.txt (work in progress),
1038
[6] Tung, B., Neuman, C., Hur, M., Medvinsky, A. and S. Medvinsky,
1039
"Public Key Cryptography for Initial Authentication in
1040
Kerberos", draft-ietf-cat-kerberos-pk-init-19.txt (work in
1041
progress), April 2004.
1049
EMail: hartmans@mit.edu
1064
Hartman Expires April 24, 2005 [Page 19]
1066
Internet-Draft Kerberos Preauth Framework October 2004
1069
Appendix A. Todo List
1071
Flesh out sections that are still outlines
1072
Discuss cookies and multiple-round-trip mechanisms.
1073
Talk about checksum contributions from each mechanism
1120
Hartman Expires April 24, 2005 [Page 20]
1122
Internet-Draft Kerberos Preauth Framework October 2004
1125
Intellectual Property Statement
1127
The IETF takes no position regarding the validity or scope of any
1128
Intellectual Property Rights or other rights that might be claimed to
1129
pertain to the implementation or use of the technology described in
1130
this document or the extent to which any license under such rights
1131
might or might not be available; nor does it represent that it has
1132
made any independent effort to identify any such rights. Information
1133
on the procedures with respect to rights in RFC documents can be
1134
found in BCP 78 and BCP 79.
1136
Copies of IPR disclosures made to the IETF Secretariat and any
1137
assurances of licenses to be made available, or the result of an
1138
attempt made to obtain a general license or permission for the use of
1139
such proprietary rights by implementers or users of this
1140
specification can be obtained from the IETF on-line IPR repository at
1141
http://www.ietf.org/ipr.
1143
The IETF invites any interested party to bring to its attention any
1144
copyrights, patents or patent applications, or other proprietary
1145
rights that may cover technology that may be required to implement
1146
this standard. Please address the information to the IETF at
1150
Disclaimer of Validity
1152
This document and the information contained herein are provided on an
1153
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1154
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1155
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1156
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1157
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1158
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1163
Copyright (C) The Internet Society (2004). This document is subject
1164
to the rights, licenses and restrictions contained in BCP 78, and
1165
except as set forth therein, the authors retain all their rights.
1170
Funding for the RFC Editor function is currently provided by the
1176
Hartman Expires April 24, 2005 [Page 21]
added
removed
doc/standardisation/draft-ietf-krb-wg-preauth-framework-02.txt
