1
Kerberos Working Group S. Hartman
3
Expires: January 17, 2005 July 19, 2004
7
A Generalized Framework for Kerberos Pre-Authentication
8
draft-ietf-krb-wg-preauth-framework-01
14
By submitting this Internet-Draft, I certify that any applicable
15
patent or other IPR claims of which I am aware have been disclosed,
16
and any of which I become aware will be disclosed, in accordance with
20
Internet-Drafts are working documents of the Internet Engineering
21
Task Force (IETF), its areas, and its working groups. Note that other
22
groups may also distribute working documents as Internet-Drafts.
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."
31
The list of current Internet-Drafts can be accessed at http://
32
www.ietf.org/ietf/1id-abstracts.txt.
35
The list of Internet-Draft Shadow Directories can be accessed at
36
http://www.ietf.org/shadow.html.
39
This Internet-Draft will expire on January 17, 2005.
45
Copyright (C) The Internet Society (2004). All Rights Reserved.
51
Kerberos is a protocol for verifying the identity of principals
52
(e.g., a workstation user or a network server) on an open network.
53
The Kerberos protocol provides a mechanism called pre-authentication
54
for proving the identity of a principal and for better protecting
55
the long-term secret of the principal.
58
This document describes a model for Kerberos pre-authentication
59
mechanisms. The model describes what state in the Kerberos request a
60
pre-authentication mechanism is likely to change. It also describes
61
how multiple pre-authentication mechanisms used in the same request
67
Hartman Expires January 17, 2005 [Page 1]
68
Internet-Draft Kerberos Preauth Framework July 2004
72
This document also provides common tools needed by multiple
73
pre-authentication mechanisms.
76
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
77
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
78
document are to be interpreted as described in [1].
84
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
85
2. Model for Pre-Authentication . . . . . . . . . . . . . . . . . 4
86
2.1 Information Managed by Model . . . . . . . . . . . . . . . 5
87
2.2 The Preauth_Required Error . . . . . . . . . . . . . . . . 7
88
2.3 Client to KDC . . . . . . . . . . . . . . . . . . . . . . 7
89
2.4 KDC to Client . . . . . . . . . . . . . . . . . . . . . . 8
90
3. Pre-Authentication Facilities . . . . . . . . . . . . . . . . 9
91
3.1 Client Authentication . . . . . . . . . . . . . . . . . . 10
92
3.2 Strengthen Reply Key . . . . . . . . . . . . . . . . . . . 10
93
3.3 Replace Reply Key . . . . . . . . . . . . . . . . . . . . 11
94
3.4 Verify Response . . . . . . . . . . . . . . . . . . . . . 11
95
4. Requirements for Pre-Authentication Mechanisms . . . . . . . . 12
96
5. Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 13
97
5.1 Combine Keys . . . . . . . . . . . . . . . . . . . . . . . 13
98
5.2 Signing Requests/Responses . . . . . . . . . . . . . . . . 13
99
5.3 Managing State for the KDC . . . . . . . . . . . . . . . . 13
100
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
101
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
102
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
103
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17
104
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
105
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 17
106
9.2 Informative References . . . . . . . . . . . . . . . . . . . 17
107
A. Todo List . . . . . . . . . . . . . . . . . . . . . . . . . . 18
108
Intellectual Property and Copyright Statements . . . . . . . . 19
127
Hartman Expires January 17, 2005 [Page 2]
128
Internet-Draft Kerberos Preauth Framework July 2004
135
The core Kerberos specification treats pre-authentication data as an
136
opaque typed hole in the messages to the KDC that may influence the
137
reply key used to encrypt the KDC response. This generality has been
138
useful: pre-authentication data is used for a variety of extensions
139
to the protocol, many outside the expectations of the initial
140
designers. However, this generality makes designing the more common
141
types of pre-authentication mechanisms difficult. Each mechanism
142
needs to specify how it interacts with other mechanisms. Also,
143
problems like combining a key with the long-term secret or proving
144
the identity of the user are common to multiple mechanisms. Where
145
there are generally well-accepted solutions to these problems, it is
146
desirable to standardize one of these solutions so mechanisms can
147
avoid duplication of work. In other cases, a modular approach to
148
these problems is appropriate. The modular approach will allow new
149
and better solutions to common pre-authentication problems to be used
150
by existing mechanisms as they are developed.
153
This document specifies a framework for Kerberos pre-authentication
154
mechanisms. IT defines the common set of functions
155
pre-authentication mechanisms perform as well as how these functions
156
affect the state of the request and response. In addition several
157
common tools needed by pre-authentication mechanisms are provided.
158
Unlike [3], this framework is not complete--it does not describe all
159
the inputs and outputs for the pre-authentication mechanisms.
160
Mechanism designers should try to be consistent with this framework
161
because doing so will make their mechanisms easier to implement.
162
Kerberos implementations are likely to have plugin architectures for
163
pre-authentication; such architectures are likely to support
164
mechanisms that follow this framework plus commonly used extensions.
167
This document should be read only after reading the documents
168
describing the Kerberos cryptography framework [3] and the core
169
Kerberos protocol [2]. This document freely uses terminology and
170
notation from these documents without reference or further
187
Hartman Expires January 17, 2005 [Page 3]
188
Internet-Draft Kerberos Preauth Framework July 2004
192
2. Model for Pre-Authentication
195
when a Kerberos client wishes to obtain a ticket using the
196
authentication server, it sends an initial AS request. If
197
pre-authentication is being used, then the KDC will respond with a
198
KDC_ERR_PREAUTH_REQUIRED error. Alternatively, if the client knows
199
what pre-authentication to use, it MAY optimize a round-trip and send
200
an initial request with padata included. If the client includes the
201
wrong padata, the server MAY return KDC_ERR_PREAUTH_FAILED with no
202
indication of what padata should have been included. For
203
interoperability reasons, clients that include optimistic
204
pre-authentication MUST retry with no padata and examine the
205
KDC_ERR_PREAUTH_REQUIRED if they receive a KDC_ERR_PREAUTH_FAILED in
206
response to their initial optimistic request.
209
The KDC maintains no state between two requests; subsequent requests
210
may even be processed by a different KDC. On the other hand, the
211
client treats a series of exchanges with KDCs as a single
212
authentication session. Each exchange accumulates state and
213
hopefully brings the client closer to a successful authentication.
216
These models for state management are in apparent conflict. For many
217
of the simpler pre-authentication scenarios, the client uses one
218
round trip to find out what mechanisms the KDC supports. Then the
219
next request contains sufficient pre-authentication for the KDC to be
220
able to return a successful response. For these simple scenarios,
221
the client only sends one request with pre-authentication data and so
222
the authentication session is trivial. For more complex
223
authentication sessions, the KDC needs to provide the client with a
224
cookie to include in future requests to capture the current state of
225
the authentication session. Handling of multiple round-trip
226
mechanisms is discussed in Section 5.3.
229
This framework specifies the behavior of Kerberos pre-authentication
230
mechanisms used to identify users or to modify the reply key used to
231
encrypt the KDC response. The padata typed hole may be used to carry
232
extensions to Kerberos that have nothing to do with proving the
233
identity of the user or establishing a reply key. These extensions
234
are outside the scope of this framework. However mechanisms that do
235
accomplish these goals should follow this framework.
238
This framework specifies the minimum state that a Kerberos
239
implementation needs to maintain while handling a request in order to
240
process pre-authentication. It also specifies how Kerberos
241
implementations process the pre-authentication data at each step of
242
the AS request process.
249
Hartman Expires January 17, 2005 [Page 4]
250
Internet-Draft Kerberos Preauth Framework July 2004
254
2.1 Information Managed by Model
257
The following information is maintained by the client and KDC as each
258
request is being processed:
259
o The reply key used to encrypt the KDC response
260
o How strongly the identity of the client has been authenticated
261
o Whether the reply key has been used in this authentication session
262
o Whether the reply key has been replaced in this authentication
264
o Whether the contents of the KDC response can be verified by the
266
o Whether the contents of the KDC response can be verified by the
270
Conceptually, the reply key is initially the long-term key of the
271
principal. However, principals can have multiple long-term keys
272
because of support for multiple encryption types, salts and
273
string2key parameters. As described in section 5.2.7.5 of the
274
Kerberos protocol [2], the KDC sends PA-ETYPe-INFO2 to notify the
275
client what types of keys are available. Thus in full generality,
276
the reply key in the pre-authentication model is actually a set of
277
keys. At the beginning of a request, it is initialized to the set of
278
long-term keys advertised in the PA-ETYPE-INFO2 element on the KDC.
279
If multiple reply keys are available, the client chooses which one to
280
use. Thus the client does not need to treat the reply key as a set.
281
At the beginning of a handling a request, the client picks a reply
285
KDC implementations MAY choose to offer only one key in the
286
PA-ETYPE-INFO2 element. Since the KDC already knows the client's
287
list of supported enctypes from the request, no interoperability
288
problems are created by choosing a single possible reply key. This
289
way, the KDC implementation avoids the complexity of treating the
293
At the beginning of handling a message on both the client and KDC,
294
the client's identity is not authenticated. A mechanism may indicate
295
that it has successfully authenticated the client's identity. This
296
information is useful to keep track of on the client in order to
297
know what pre-authentication mechanisms should be used. The KDC
298
needs to keep track of whether the client is authenticated because
299
the primary purpose of pre-authentication is to authenticate the
300
client identity before issuing a ticket. Implementations that have
301
pre-authentication mechanisms offering significantly different
302
strengths of client authentication MAY choose to keep track of the
303
strength of the authentication used as an input into policy
304
decisions. For example, some principals might require strong
305
pre-authentication, while less sensitive principals can use
310
Hartman Expires January 17, 2005 [Page 5]
311
Internet-Draft Kerberos Preauth Framework July 2004
315
relatively weak forms of pre-authentication like encrypted timestamp.
318
Initially the reply key has not been used. A pre-authentication
319
mechanism that uses the reply key either directly to encrypt or
320
checksum some data or indirectly in the generation of new keys MUST
321
indicate that the reply key is used. This state is maintained by the
322
client and KDC to enforce the security requirement stated in Section
323
3.3 that the reply key cannot be replaced after it is used.
326
Initially the reply key has not been replaced. If a mechanism
327
implements the Replace Reply Key facility discussed in Section 3.3,
328
then the state MUST be updated to indicate that the reply key has
329
been replaced. Once the reply key has been replaced, knowledge of the
330
reply key is insufficient to authenticate the client. The reply key
331
is marked replaced in exactly the same situations as the KDC reply
332
is marked as not being verified to the client principal. However,
333
while mechanisms can verify the KDC request to the client, once the
334
reply key is replaced, then the reply key remains replaced for the
335
remainder of the authentication session.
338
Without pre-authentication, the client knows that the KDC request is
339
authentic and has not been modified because it is encrypted in the
340
long-term key of the client. Only the KDC and client know that key.
341
So at the start of handling any message the KDC request is presumed
342
to be verified to the client principal. Any pre-authentication
343
mechanism that sets a new reply key not based on the principal's
344
long-term secret MUST either verify the KDC response some other way
345
or indicate that the response is not verified. If a mechanism
346
indicates that the response is not verified then the client
347
implementation MUST return an error unless a subsequent mechanism
348
verifies the response. The KDC needs to track this state so it can
349
avoid generating a response that is not verified.
352
The typical Kerberos request does not provide a way for the client
353
machine to know that it is talking to the correct KDC. Someone who
354
can inject packets into the network between the client machine and
355
the KDC and who knows the password that the user will give to the
356
client machine can generate a KDC response that will decrypt
357
properly. So, if the client machine needs to authenticate that the
358
user is in fact the named principal, then the client machine needs to
359
do a TGS request for itself as a service. Some pre-authentication
360
mechanisms may provide a way for the client to authenticate the KDC.
361
Examples of this include signing the response with a well-known
362
public key or providing a ticket for the client machine as a service
363
in addition to the requested ticket.
371
Hartman Expires January 17, 2005 [Page 6]
372
Internet-Draft Kerberos Preauth Framework July 2004
376
2.2 The Preauth_Required Error
379
Typically a client starts an authentication session by sending an
380
initial request with no pre-authentication. If the KDC requires
381
pre-authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED
382
message. This message MAY also be returned for pre-authentication
383
configurations that use multi-round-trip mechanisms. This error
384
contains a sequence of padata. Typically the padata contains the
385
pre-authentication type IDs of all the available pre-authentication
386
mechanisms. IN the initial error response, most mechanisms do not
387
contain data. If a mechanism requires multiple round trips or starts
388
with a challenge from the KDC to the client, then it will likely
389
contain data in the initial error response.
392
The KDC SHOULD NOT send data that is encrypted in the long-term
393
password-based key of the principal. Doing so has the same security
394
exposures as the Kerberos protocol without pre-authentication. There
395
are few situations where pre-authentication is desirable and where
396
the KDC needs to expose ciphertext encrypted in a weak key before the
397
client has proven knowledge of that key.
400
In order to generate the error response, the KDC first starts by
401
initializing the pre-authentication state. Then it processes any
402
padata in the client's request in the order provided by the client.
403
Mechanisms that are not understood by the KDC are ignored.
404
Mechanisms that are inappropriate for the client principal or request
405
SHOULD also be ignored. Next, it generates padata for the error
406
response, modifying the pre-authentication state appropriately as
407
each mechanism is processed. The KDC chooses the order in which it
408
will generated padata (and thus the order of padata in the response),
409
but it needs to modify the pre-authentication state consistently with
410
the choice of order. For example, if some mechanism establishes an
411
authenticated client identity, then the mechanisms subsequent in the
412
generated response receive this state as input. After the padata is
413
generated, the error response is sent.
419
This description assumes a client has already received a
420
KDC_ERR_PREAUTH_REQUIRED from the KDC. If the client performs
421
optimistic pre-authentication then the client needs to optimisticly
422
choose the information it would normally receive from that error
426
The client starts by initializing the pre-authentication state as
427
specified. It then processes the pdata in the
428
KDC_ERR_PREAUTH_REQUIRED.
434
Hartman Expires January 17, 2005 [Page 7]
435
Internet-Draft Kerberos Preauth Framework July 2004
439
After processing the pdata in the KDC error, the client generates a
440
new request. It processes the pre-authentication mechanisms in the
441
order in which they will appear in the next request, updating the
442
state as appropriate. When the request is complete it is sent.
448
When a KDC receives an AS request from a client, it needs to
449
determine whether it will respond with an error or a AS reply.
450
There are many causes for an error to be generated that have nothing
451
to do with pre-authentication; they are discussed in the Kerberos
455
From the standpoint of evaluating the pre-authentication, the KDC
456
first starts by initializing the pre-authentication state. IT then
457
processes the padata in the request. AS mentioned in Section 2.2,
458
the KDC MAY ignore padata that is inappropriate for the configuration
459
and MUST ignore padata of an unknown type.
462
At this point the KDC decides whether it will issue a
463
pre-authentication required error or a reply. Typically a KDC will
464
issue a reply if the client's identity has been authenticated to a
465
sufficient degree. The processing of the pre-authentication required
466
error is described in Section 2.2.
469
The KDC generates the pdata modifying the pre-authentication state as
470
necessary. Then it generates the final response, encrypting it in
471
the current pre-authentication reply key.
496
Hartman Expires January 17, 2005 [Page 8]
497
Internet-Draft Kerberos Preauth Framework July 2004
501
3. Pre-Authentication Facilities
504
Pre-Authentication mechanisms can be thought of as providing various
505
conceptual facilities. This serves two useful purposes. First,
506
mechanism authors can choose only to solve one specific small
507
problem. It is often useful for a mechanism designed to offer key
508
management not to directly provide client authentication but instead
509
to allow one or more other mechanisms to handle this need. Secondly,
510
thinking about the abstract services that a 2mechanism provides
511
yields a minimum set of security requirements that all mechanisms
512
providing that facility must meet. These security requirements are
513
not complete; mechanisms will have additional security requirements
514
based on the specific protocol they employ.
517
A mechanism is not constrained to only offering one of these
518
facilities. While such mechanisms can be designed and are sometimes
519
useful, many pre-authentication mechanisms implement several
520
facilities. By combining multiple facilities in a single mechanism,
521
it is often easier to construct a secure, simple solution than by
522
solving the problem in full generality. Even when mechanisms provide
523
multiple facilities, they need to meet the security requirements for
524
all the facilities they provide.
527
According to Kerberos extensibility rules (section 1.4.2 of the
528
Kerberos specification [2]), an extension MUST NOT change the
529
semantics of a message unless a recipient is known to understand that
530
extension. Because a client does not know that the KDC supports a
531
particular pre-authentication mechanism when it sends an initial
532
request, a preauth mechanism MUST NOT change the semantics of the
533
request in a way that will break a KDC that does not understand that
534
mechanism. Similarly, KDCs MUST not send messages to clients that
535
affect the core semantics unless the clients have indicated support
539
The only state in this model that would break the interpretation of a
540
message is changing the expected reply key. If one mechanism changed
541
the reply key and a later mechanism used that reply key, then a KDC
542
that interpreted the second mechanism but not the first would fail to
543
interpret the request correctly. In order to avoid this problem,
544
extensions that change core semantics are typically divided into two
545
parts. The first part proposes a change to the core semantic--for
546
example proposes a new reply key. The second part acknowledges that
547
the extension is understood and that the change takes effect. Section
548
3.2 discusses how to design mechanisms that modify the reply key to
549
be split into a proposal and acceptance without requiring additional
550
round trips to use the new reply key in subsequent
551
pre-authentication. Other changes in the state described in Section
552
2.1 can safely be ignored by a KDC that does not understand a
557
Hartman Expires January 17, 2005 [Page 9]
558
Internet-Draft Kerberos Preauth Framework July 2004
562
mechanism. Mechanisms that modify the behavior of the request
563
outside the scope of this framework need to carefully consider the
564
Kerberos extensibility rules to avoid similar problems.
567
3.1 Client Authentication
570
The client authentication facility proves the identity of a user to
571
the KDC before a ticket is issued. Examples of mechanisms
572
implementing this facility include the encrypted timestamp facility
573
defined in Section 5.2.7.2 of the Kerberos specification [2] and the
574
single-use mechanism defined in [5]. Mechanisms that provide this
575
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.
587
If the reply key has been replaced, then mechanisms such as encrypted
588
timestamp that rely on knowledge of the reply key to authenticate the
589
client MUST NOT be used.
592
3.2 Strengthen Reply Key
595
Particularly, when dealing with keys based on passwords, it is
596
desirable to increase the strength of the key by adding additional
597
secrets to it. Examples of sources of additional secrets include the
598
results of a Diffie-Hellman key exchange or key bits from the output
599
of a smart card [5]. Typically these additional secrets are
600
converted into a Kerberos protocol key. Then they are combined with
601
the existing reply key as discussed in Section 5.1.
604
If a mechanism implementing this facility wishes to modify the reply
605
key before knowing that the other party in the exchange supports the
606
mechanism, it proposes modifying the reply key. The other party then
607
includes a message indicating that the proposal is accepted if it is
608
understood and meets policy. In many cases it is desirable to use
609
the new reply key for client authentication and for other facilities.
610
Waiting for the other party to accept the proposal and actually
611
modify the reply key state would add an additional round trip to the
612
exchange. Instead, mechanism designers are encouraged to include a
613
typed hole for additional padata in the message that proposes the
614
reply key change. The padata included in the typed hole are
615
generated assuming the new reply key. If the other party accepts the
616
proposal, then these padata are interpreted as if they were included
621
Hartman Expires January 17, 2005 [Page 10]
622
Internet-Draft Kerberos Preauth Framework July 2004
626
immediately following the proposal. The party generating the
627
proposal can determine whether the padata were processed based on
628
whether the proposal for the reply key is accepted.
631
The specific formats of the proposal message, including where padata
632
are are included is a matter for the mechanism specification.
633
Similarly, the format of the message accepting the proposal is
637
Mechanisms implementing this facility and including a typed hole for
638
additional padata MUST checksum that padata using a keyed checksum or
639
encrypt the padata. Typically the reply key is used to protect the
640
padata. XXX If you are only minimally increasing the strength of the
641
reply key, this may give the attacker access to something too close
642
to the original reply key. However, binding the padata to the new
643
reply key seems potentially important from a security standpoint.
644
There may also be objections to this from a double encryption
645
standpoint because we also recommend client authentication facilities
646
be tied to the reply key.
649
3.3 Replace Reply Key
652
The Replace Reply Key facility replaces the key in which a successful
653
AS reply will be encrypted. This facility can only be used in
654
cases where knowledge of the reply key is not used to authenticate
655
the client. The new reply key MUST be communicated to the client and
656
KDC in a secure manner. Mechanisms implementing this facility MUST
657
mark the reply key as replaced in the pre-authentication state.
658
Mechanisms implementing this facility MUST either provide a mechanism
659
to verify the KDC reply to the client or mark the reply as unverified
660
in the pre-authentication state. Mechanisms implementing this
661
facility SHOULD NOT be used if a previous mechanism has used the
665
As with the Strengthen Reply Key facility, Kerberos extensibility
666
rules require that the reply key not be changed unless both sides of
667
the exchange understand the extension. In the case of this facility
668
it will likely be more common for both sides to know that the
669
facility is available by the time that the new key is available to be
670
used. However, mechanism designers can use a container for padata in
671
a proposal message as discussed in Section 3.2 if appropriate.
684
Hartman Expires January 17, 2005 [Page 11]
685
Internet-Draft Kerberos Preauth Framework July 2004
689
4. Requirements for Pre-Authentication Mechanisms
692
State management for multi-round-trip mechs
693
Security interactions with other mechs
742
Hartman Expires January 17, 2005 [Page 12]
743
Internet-Draft Kerberos Preauth Framework July 2004
747
5. Tools for Use in Pre-Authentication Mechanisms
753
5.2 Signing Requests/Responses
756
5.3 Managing State for the KDC
802
Hartman Expires January 17, 2005 [Page 13]
803
Internet-Draft Kerberos Preauth Framework July 2004
807
6. IANA Considerations
859
Hartman Expires January 17, 2005 [Page 14]
860
Internet-Draft Kerberos Preauth Framework July 2004
864
7. Security Considerations
867
Very little of the AS request is authenticated. Same for padata
868
in the reply or error. Discuss implications
869
Table of security requirements stated elsewhere in the document
917
Hartman Expires January 17, 2005 [Page 15]
918
Internet-Draft Kerberos Preauth Framework July 2004
974
Hartman Expires January 17, 2005 [Page 16]
975
Internet-Draft Kerberos Preauth Framework July 2004
982
9.1 Normative References
985
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
986
Levels", RFC 2119, BCP 14, March 1997.
989
[2] Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos
990
Network Authentication Service (V5)",
991
draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in
992
progress), June 2004.
995
[3] Raeburn, K., "Encryption and Checksum Specifications for
996
Kerberos 5", draft-ietf-krb-wg-crypto-03.txt (work in progress).
999
[4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
1003
9.2 Informative References
1006
[5] Hornstein, K., Renard, K., Neuman, C. and G. Zorn, "Integrating
1007
Single-use Authentication Mechanisms with Kerberos",
1008
draft-ietf-krb-wg-kerberos-sam-02.txt (work in progress),
1012
[6] Tung, B., Neuman, C., Hur, M., Medvinsky, A. and S. Medvinsky,
1013
"Public Key Cryptography for Initial Authentication in
1014
Kerberos", draft-ietf-cat-kerberos-pk-init-19.txt (work in
1015
progress), April 2004.
1026
EMail: hartmans@mit.edu
1042
Hartman Expires January 17, 2005 [Page 17]
1043
Internet-Draft Kerberos Preauth Framework July 2004
1047
Appendix A. Todo List
1050
Flesh out sections that are still outlines
1051
Discuss cookies and multiple-round-trip mechanisms.
1052
Talk about checksum contributions from each mechanism
1100
Hartman Expires January 17, 2005 [Page 18]
1101
Internet-Draft Kerberos Preauth Framework July 2004
1105
Intellectual Property Statement
1108
The IETF takes no position regarding the validity or scope of any
1109
Intellectual Property Rights or other rights that might be claimed to
1110
pertain to the implementation or use of the technology described in
1111
this document or the extent to which any license under such rights
1112
might or might not be available; nor does it represent that it has
1113
made any independent effort to identify any such rights. Information
1114
on the IETF's procedures with respect to rights in IETF Documents can
1115
be found in BCP 78 and BCP 79.
1118
Copies of IPR disclosures made to the IETF Secretariat and any
1119
assurances of licenses to be made available, or the result of an
1120
attempt made to obtain a general license or permission for the use of
1121
such proprietary rights by implementers or users of this
1122
specification can be obtained from the IETF on-line IPR repository at
1123
http://www.ietf.org/ipr.
1126
The IETF invites any interested party to bring to its attention any
1127
copyrights, patents or patent applications, or other proprietary
1128
rights that may cover technology that may be required to implement
1129
this standard. Please address the information to the IETF at
1134
Disclaimer of Validity
1137
This document and the information contained herein are provided on an
1138
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1139
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1140
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1141
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1142
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1143
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1150
Copyright (C) The Internet Society (2004). This document is subject
1151
to the rights, licenses and restrictions contained in BCP 78, and
1152
except as set forth therein, the authors retain all their rights.
1159
Funding for the RFC Editor function is currently provided by the
1165
Hartman Expires January 17, 2005 [Page 19]
b'\\ No newline at end of file'
added
removed
doc/standardisation/draft-ietf-krb-wg-preauth-framework-01.txt
