| blob | fa5fa9bd72ac79e625124ec4fd16118f1b8dab65 |
7 INTERNET-DRAFT Clifford Neuman
8 <draft-ietf-krb-wg-kerberos-sam-00.txt> ISI
9 Updates: RFC 1510 Glen Zorn
10 September 18, 2002 Cisco Systems
11 Ken Hornstein
12 Naval Research Laboratory
13 Ken Renard
14 WareOnEarth
18 Integrating Single-use Authentication Mechanisms with Kerberos
21 0. Status Of this Memo
22 This document is an Internet-Draft and is subject to all provisions
23 of Section 10 of RFC2026. Internet-Drafts are working documents of
24 the Internet Engineering Task Force (IETF), its areas, and its
25 working groups. Note that other groups may also distribute working
26 documents as Internet-Drafts.
28 Internet-Drafts are draft documents valid for a maximum of six
29 months and may be updated, replaced, or obsoleted by other docu-
30 ments at any time. It is inappropriate to use Internet-Drafts as
31 reference material or to cite them other than as ``work in pro-
32 gress.''
34 The list of current Internet-Drafts can be accessed at
35 http://www.ietf.org/1id-abstracts.html
37 The list of Internet-Draft Shadow Directories can be accessed at
38 http://www.ietf.org/shadow.html
40 The distribution of this memo is unlimited. It is filed as
41 <draft-ietf-kerberos-sam-00.txt>, and expires December 22, 2002.
42 Please send comments to the authors.
45 1. Abstract
46 This document defines extensions to the Kerberos protocol specifi-
47 cation [RFC1510] which provide a method by which a variety of
48 single-use authentication mechanisms may be supported within the
49 protocol. The method defined specifies a standard fashion in which
50 the preauthentication data and error data fields in Kerberos mes-
51 sages may be used to support single-use authentication mechanisms.
54 2. Terminology
55 To simplify the following discussion, we will define those terms
56 which may be unfamiliar to the audience or specific to the discus-
57 sion itself.
59 Single-use Preauthentication Data (SPD): Data sent in the padata-
60 value field of a Kerberos V5 message proving that knowledge of
64 Neuman, Zorn, Hornstein, Renard [Page 1]
70 INTERNET-DRAFT September 18, 2002
73 certain unique information is held by a principal. This informa-
74 tion may or may not be identical to the single-use authentication
75 data input to the client. For example, in the case of S/Key, the
76 principal might input a one-time password (in any of several
77 forms); the knowledge of this one-time password is taken to indi-
78 cate knowledge of the principal's secret passphrase. Similarly,
79 the SPD may or may not contain the provided single-use authentica-
80 tion data. For instance, if a given single-use authentication
81 mechanism includes a token which generates an encryption key for a
82 supported cryptosystem, that key could be used to encrypt portions
83 of the SPD before transmission. As long as the verification pro-
84 cess of the mechanism was capable of independently generating the
85 same key, the successful decryption of the SPD would provide
86 assurance that the originator of the message was in possession of
87 the token, as well as whatever information the token required to
88 generate the encryption key.
90 Single-use Authentication Mechanism (SAM): A system for generating
91 and verifying authentication data which is usable only once.
93 Single-use Authentication Data (SAD): SAM-specific data provided
94 by a principal as input to client software to be used in the crea-
95 tion of SPD.
98 3. Motivation and Scope
99 Several single-use authentication mechanisms are currently in
100 widespread use, including hardware-based schemes from vendors such
101 as Enigma Logic, CRYPTOCard, and Security Dynamics and software-
102 based methods like S/Key [RFC1760]. The hardware-based schemes
103 typically require that the authenticating user carry a small,
104 credit-card-sized electronic device (called a token) which is used
105 to generate unique authentication data. Some tokens require the
106 user to enter data into the device. This input may take the form
107 of a Personal Identification Number (PIN), a server-generated chal-
108 lenge string or both. Other tokens do not use a challenge-response
109 technique, instead spontaneously generating new and unique authen-
110 tication data every few seconds. These tokens are usually time-
111 synchronized with a server. The use of one-time passwords and
112 token cards as an authentication mechanism has steadily increased
113 over the past few years; in addition, the Internet Architecture
114 Board has encouraged the use of SAMs to improve Internet security
115 [RFC1636].
117 The widespread acceptance of Kerberos within the Internet community
118 has produced considerable demand for the integration of SAM tech-
119 nology with the authentication protocol. Several currently avail-
120 able implementations of Kerberos include support for some types of
121 token cards, but the implementations are either not interoperable,
122 or would require the release of source code (not always an option)
123 to make them interoperate. This memo attempts to remedy that prob-
124 lem by specifying a method in which SAM data may be securely tran-
125 sported in Kerberos V5 messages in a standard, extensible fashion.
126 This document does not, however, attempt to precisely specify
130 Neuman, Zorn, Hornstein, Renard [Page 2]
136 INTERNET-DRAFT September 18, 2002
139 either the generation or verification of SAM data, since this is
140 likely to be SAM-specific; nor does it dictate the conditions under
141 which SAM data must be included in Kerberos messages, since we con-
142 sider this to be a matter of local policy.
144 A primary reason for using a SAM with Kerberos is to reduce the
145 threat from common attacks on Kerberos passwords (poorly chosen
146 passwords, password guessing, etc). If passwords are used in com-
147 bination with SAM authentication data, users must still adhere to
148 sensible password policies and safe practices regarding the selec-
149 tion, secrecy, and maintenance of their passwords. Depending on
150 the specific mechanism used, the purpose of the SAD is to augment
151 (or sometimes replace) the use of a password as a secret key.
154 4. Generic Approach - Two Models
155 As outlined above, there are essentially two types of single-use
156 authentication mechanisms: challenge/response and time-based. In
157 order to support challenge/response mechanisms, the Kerberos Key
158 Distribution Center (KDC) must communicate the appropriate chal-
159 lenge string to the user, via the client software. Furthermore,
160 some challenge/response mechanisms require tight synchronization
161 between all instances of the KDC and the client. One example is
162 S/Key and its variants. If the KDC and client do not perform the
163 same number of message digest iterations, the protocol will fail;
164 worse, it might be possible for an eavesdopping attacker to capture
165 a valid S/Key passcode and replay it to a KDC replica which had an
166 outdated iteration number. In the time-based case, no challenge is
167 required. This naturally gives rise to two modes of client
168 behavior, described below.
171 4.1 Challenge/Response Model
172 The client begins with an initial KRB_AS_REQ message to the KDC,
173 possibly using existing preauthentication methods (PA-ENC-TIMESTAMP
174 (encrypted timestamp), PA-OSF-DCE (DCE), etc.). Depending on
175 whether preauthentication is used, the user may or may not be
176 prompted at this time for a Kerberos password. If (for example)
177 encrypted timestamp preauthentication is used, then the user will
178 be prompted; on the other hand, if no preauthentication is in use
179 the prompt for the password may be deferred (possibly forever).
180 Note that the use of preauthentication here may allow an offline
181 guessing attack against the Kerberos password separate from the
182 SPD. However, if the use of a SAM is required, then the password
183 by itself is not sufficient for authentication. (Specify character
184 strings as UTF-8)
186 The KDC will determine in an implementation- and policy-dependent
187 fashion if the client is required to utilize a single-use authenti-
188 cation mechanism. For example, the implementation may use IP
189 address screening to require principals authenticating from outside
190 a firewall to use a SAM, while principals on the inside need not.
191 If SAM usage is required, then the KDC will respond with a
192 KRB_ERROR message, with the error-code field set to
196 Neuman, Zorn, Hornstein, Renard [Page 3]
202 INTERNET-DRAFT September 18, 2002
205 KDC_ERR_PREAUTH_REQUIRED and the e-data field containing the ASN.1
206 structure that is a sequence of PA-DATA fields.
208 If the type of one of the PA-DATA fields is PA-SAM-REDIRECT, the
209 client should re-execute the authentication protocol from the
210 beginning, directing messages to another of the KDCs for the realm.
211 This is done to allow some methods to require that a single KDC be
212 used for SAM authentication when tight synchronization is needed
213 between all replicas and the KDC database propagation code does not
214 provide such synchronization. The corresponding padata-value will
215 contain an encoded sequence of host addresses [RFC1510], from which
216 the client must choose the KDC to be contacted next. The PA-SAM-
217 REDIRECT is defined as:
220 PA-SAM-REDIRECT ::= HostAddresses
223 Client implementations SHOULD check the addresses in the PA-SAM-
224 REDIRECT and verify that they are a subset of the KDC addresses
225 that they have been configured for that realm.
227 If none of the PA-DATA fields have a value of PA-SAM-REDIRECT, then
228 if one of the PA-DATA fields has the type PA-SAM-CHALLENGE-2, the
229 exchange will continue as described in section 5, below.
231 Note that some Kerberos implementations support an older preauthen-
232 tication mechanism with the padata types PA-SAM-CHALLENGE and PA-
233 SAM-RESPONSE. That protocol is depreciated and not defined here.
236 4.2 Time-based Model
237 For mechanisms where no challenge is required, the user (or the
238 client software being utilized) may or may not know a priori
239 whether SAM usage is required. If it does not know, then the ini-
240 tial exchange may proceed as above. If it is known that a use of a
241 single-use authentication mechanism is required then the first
242 exchange can be skipped and the authentication will continue as
243 follows.
246 5. SAM Preauthentication
248 An optional SAM-CHALLENGE-2 may be sent from the KDC to the client
249 and the client will send a SAM-RESPONSE-2 as pre-authentication
250 data in the KRB-AS-REQ. The details of the messages follow.
252 5.1 SAM-CHALLENGE-2
254 Prior to performing preauthentication using a single-use authenti-
255 cation mechanism, the client must know whether a challenge is
256 required (if the client doesn't have this information prior to its
257 sending the first KRB_AS_REQ message, it will be informed of the
258 requirement by the KDC, as described in section 4.1). The client
262 Neuman, Zorn, Hornstein, Renard [Page 4]
268 INTERNET-DRAFT September 18, 2002
271 does NOT need to know the specific type of SAM in use. If a chal-
272 lenge is required the client will be sent the challenge by the KDC.
273 This means that a client supporting SAMs will be able to work with
274 new methods without modification. The challenge, as well as all
275 other prompts mentioned herein, can be internationalized by the KDC
276 on a per-principal basis.
278 If a KRB_ERROR message is received from the KDC indicating that SAM
279 usage is required, that message will include in its e-data field a
280 PA-DATA structure that encodes information about the SAM to be
281 used. This includes whether a challenge is required, and if so,
282 the challenge itself; and informational data about the type of SAM
283 that is in use, and how to prompt for the SAD. The SAM type is
284 informational only and does not affect the behavior of the client.
285 The prompt is also informational and may be presented to the user
286 by the client, or it may be safely ignored.
288 The ASN.1 definition for the SAM challenge is:
290 PA-SAM-CHALLENGE-2 ::= SEQUENCE {
291 sam-type[0] INTEGER,
292 sam-flags[1] SAMFlags,
293 sam-type-name[2] GeneralString OPTIONAL,
294 sam-track-id[3] GeneralString OPTIONAL,
295 sam-challenge-label[4] GeneralString OPTIONAL,
296 sam-challenge[5] GeneralString OPTIONAL,
297 sam-response-prompt[6] GeneralString OPTIONAL,
298 sam-pk-for-sad[7] EncryptionKey OPTIONAL,
299 sam-nonce[8] INTEGER,
300 sam-cksum[9] SEQUENCE OF Checksum,
301 sam-etype[10] INTEGER,
302 ...
303 }
305 SAMFlags ::= BIT STRING {
306 use-sad-as-key[0],
307 send-encrypted-sad[1],
308 must-pk-encrypt-sad[2],
309 ...
310 }
312 5.1.1 SAM-TYPE and SAM-TYPE-NAME Fields
314 The sam-type field is informational only, but it must be specified
315 and sam-type values must be registered with the IANA.
317 Initially defined values of the sam-type codes are:
319 PA_SAM_TYPE_ENIGMA 1 -- Enigma Logic
320 PA_SAM_TYPE_DIGI_PATH 2 -- Digital Pathways
321 PA_SAM_TYPE_SKEY_K0 3 -- S/key where KDC has key 0
322 PA_SAM_TYPE_SKEY 4 -- Traditional S/Key
323 PA_SAM_TYPE_SECURID 5 -- Security Dynamics
324 PA_SAM_TYPE_CRYPTOCARD 6 -- CRYPTOCard
328 Neuman, Zorn, Hornstein, Renard [Page 5]
334 INTERNET-DRAFT September 18, 2002
337 PA_SAM_TYPE_SECURID, PA_SAM_TYPE_DIGI_PATH, PA_SAM_TYPE_ENIGMA, and
338 PA_SAM_TYPE_CRYPTOCARD represent popular token cards.
339 PA_SAM_TYPE_SKEY is the traditional S/Key protocol, in which the
340 SAD verifier does not have knowledge of the principal's S/Key
341 secret. PA_SAM_TYPE_SKEY_K0 is a variant of S/Key that uses the
342 same SAD and PC software or hardware device, but where the zeroth
343 key (the S/Key secret) is actually stored on, and can be used by,
344 the SAD verifier to independently generate the correct authentica-
345 tion data.
347 Note that using PA_SAM_TYPE_SKEY_K0 gives up one advantage of
348 S/Key, viz., that the information required to generate the SAD need
349 not be stored on the host; but since the SAD verifier (which may be
350 the KDC) is assumed to be more secure than other hosts on the net-
351 work, it may be acceptable to give up this advantage in some situa-
352 tions. The advantage of using this S/Key variant is that the secu-
353 rity of the network protocol is strengthened since the SAD need not
354 be sent from the client to the KDC. Thus, the SAD can be used as
355 part of the key used to encrypt the encrypted parts of both the SPD
356 and the KRB_AS_REP message, rather than being sent protected by the
357 principal's Kerberos secret key which may have been previously
358 exposed to an attacker (see section 6, below). In any case, there
359 is a definite advantage to being interoperable with the S/Key algo-
360 rithm.
362 Due to the volatility of, and rapid developments in, the area of
363 single-use authentication mechanisms (both software-only and
364 hardware supported), any subsequently defined sam-type codes will
365 be maintained by the IANA.
367 The optional sam-type-name field is a UTF-8 character string for
368 informational use only. It may be used by the client to display a
369 short description of the type of single-use authentication mechan-
370 ism to be used.
372 5.1.2 SAM-FLAGS Field
374 The sam-flags field indicates whether the SAD is known by the KDC
375 (in which case it can be used as part of the encryption key for the
376 ensuing KRB_AS_REP message), or if it must be provided to the KDC
377 in a recoverable manner. If it is known to the KDC, use-sad-as-key
378 indicates that the SAD alone will be used to generate the encryp-
379 tion key for the forthcoming KRB_AS_REQ and KRB_AS_REP messages,
380 and that the user will not need to also enter a password. We
381 recommend that this option only be used if the SAD will be used to
382 generate adequate keying material (sufficient length, secrecy, ran-
383 domness) for the cryptographic algorithm used. If the single-use
384 authentication data is not known (and cannot be generated or
385 discovered) by the KDC, then send-encrypted-sad flag will be set,
386 indicating that the SAD must be sent to the KDC encrypted under the
387 principal's secret key. If neither use-sad-as-key nor send-
388 encrypted-sad are set, the client may assume that the KDC knows the
389 SAD, but the Kerberos password should be used along with the
390 passcode in the derivation of the encryption key (see below). No
394 Neuman, Zorn, Hornstein, Renard [Page 6]
400 INTERNET-DRAFT September 18, 2002
403 more than one of the send-encrypted-sad and use-sad-as-key flags
404 shoudl be in a SAM-CHALLENGE-2.
406 The must-pk-encrypt-sad flag is reserved for future use. If this
407 flag is set and a client does not support the must-pk-encrypt-sad
408 option (to be defined in a separate document), the client will not
409 be able to complete the authentication and must notify the user.
411 5.1.3 SAM-CHECKSUM Field
413 The sam-cksum field contains a sequence of at least one crypto-
414 graphic checksum of encoding of the PA-SAM-CHALLENGE-2 sequence.
415 If the send-encrypted-sad flag is set, the key to be used for this
416 checksum is the client's long-term secret. If the use-sad-as-key
417 flag is set, then the SAD alone will be used as the key. If nei-
418 ther flag is set, then the key used for this checksum is derived
419 from the SAD and the user's password (see section 5.2).
421 The checksum algorithm to be used for this is the mandatory check-
422 sum associated with the encryption algorithm specified in the sam-
423 etype field, with a key usage of 25.
425 In some cases there may be more than one valid SAD; some preauthen-
426 tication mechanisms may have a range of valid responses. In that
427 case, the KDC may elect to return multiple checksums, one for each
428 possible SAD response. The number of possible responses of course
429 depends on the mechanism and site policy. In the case where multi-
430 ple checksums are returned, the client MUST try each checksum in
431 turn until one of the checksums is verified successfully. Note
432 that in the non-send-encrypted-sad case the checksum cannot be ver-
433 ified until the user enters in the SAD, but if no checksum can be
434 verified, the client MUST not send a response but instead return an
435 error to the user.
437 The sam-cksum field is generated by encoding the entire SAM-
438 CHALLENGE-2 sequence with a zero-length sam-cksum sequence. The
439 checksums are calculated over this encoding, and the SAM-
440 CHALLENGE-2 sequence is reencoded with all of the checksums in
441 place. Checksum verification is done by reencoding the decoded
442 SAM-CHALLENGE-2 sequence with a zero-length sam-cksum and trying
443 checksums until a valid one is found.
445 If no checksum is included, or is of the wrong type, or none are
446 found which are correct, the client MUST abort the dialogue with
447 the KDC and issue, respectively, KRB5_SAM_NO_CHECKSUM,
448 KRB5_SAM_BAD_CHECKSUM_TYPE, or KRB5_SAM_BAD_CHECKSUM error mes-
449 sages.
451 5.1.4 SAM-TRACK-ID Field
453 The optional sam-track-id field may be returned by the KDC in the
454 KRB_ERROR message. If present, the client MUST copy this field
455 into the corresponding field of the SAM response sent in the subse-
456 quent KRB_AS_REQ message. This field may be used by the KDC to
460 Neuman, Zorn, Hornstein, Renard [Page 7]
466 INTERNET-DRAFT September 18, 2002
469 match challenges and responses. It might be a suitably encoded
470 integer, or even be encrypted data with the KDC state encoded so
471 that the KDC doesn't have to maintain the state internally. Note
472 that when a KDC supplies a sam-track-id, it MUST link the sam-
473 track-id with the sam-nonce field to prevent spoofing of the sam-
474 track-id field.
476 The key usage type 26 is reserved for use to encrypt the sam-
477 track-id data. The key used to encrypt the sam-track-id is
478 mechanism-dependent.
480 5.1.5 SAM-CHALLENGE-LABEL Field
482 The sam-challenge-label field is informational and optional. If it
483 is included, is will be an UTF-8 encoded character. If present, a
484 client may choose to precede the presentation of the challenge with
485 this string. For example, if the challenge is 135773 and the
486 string in the sam-challenge-label field is "Enter the following
487 number on your card", the client may choose to display to the user:
489 Enter the following number on your card: 135773
491 If no challenge label was presented, or if the client chooses to
492 ignore it, the client might display instead:
494 Challenge from authentication server: 135773
496 Internationalization is supported by allowing customization of the
497 challenge label and other strings on a per-principal basis. Note
498 that this character string should be encoded using UTF-8.
500 5.1.6 SAM-CHALLENGE Field
502 The optional sam-challenge field contains a string that will be
503 needed by the user to generate a suitable response. If the sam-
504 challenge field is left out, it indicates that the SAM in use does
505 not require a challenge, and that the authorized user should be
506 able to produce the correct SAD without one. If the sam-challenge
507 field is present, it is the data that is used by the SAD generator
508 to create the SAD to be used in the production of the SPD to be
509 included in the response.
511 5.1.7 SAM-RESPONSE-PROMPT Field
513 The sam-response-prompt field is informational and optional. If
514 present, a client may choose to precede the prompt for the response
515 with the specified string.
517 Passcode:
519 5.1.8 SAM-PK-FOR-SAD Field
521 sam-pk-for-sad is an optional field. It is included in the
522 interest of future extensability of the protocol to the use of
526 Neuman, Zorn, Hornstein, Renard [Page 8]
532 INTERNET-DRAFT September 18, 2002
535 public-key cryptography.
537 5.1.9 SAM-NONCE Field
539 The sam-nonce is a KDC-supplied nonce and should conform to the
540 specification of the nonce field in a KRB_KDC_REQ message
541 [RFC1510].
543 Challenge/Response mechanisms MUST link the nonce field with the
544 sam-track-id (if one is included) to prevent replay of the sam-
545 track-id field.
547 5.1.10 SAM-ETYPE Field
549 The sam-etype field contains the encryption type to be used by the
550 client for all encrypted fields in the PA-SAM-RESPONSE-2 message.
551 The KDC should pick an appropriate encryption algorithm based on
552 the encryption algorithms listed in the client's initial
553 KRB_AS_REQ.
555 5.2 Obtaining SAM Authentication Data
557 If the client is performing SAM preauthentication in the initial
558 message, without receipt of a PA-SAM-CHALLENGE-2 (i.e. without
559 waiting for the KRB_ERROR message), and the SAM in use does not
560 require a challenge, the client will prompt for the SAD in an
561 application-specific manner.
563 Once the user has been prompted for and entered the SAD (and possi-
564 bly the Kerberos password), the client will derive a key to be used
565 to encrypt the preauthentication data for a KRB_AS_REQ message.
566 This key will be determined as follows:
568 By default, the key is derived from the password and the SAD
569 by running each through the string_to_key function [RFC1510]
570 separately; i.e., K1 = string_to_key(password) and K2 =
571 string_to_key(SAD). The K1 and K2 are then combined to form
572 a single key K using the algorithm described in Appendix A.
574 If the send-encrypted-sad flag is set, the key will be
575 derived by running the Kerberos password though the
576 string_to_key function in the normal fashion.
578 If the use-sad-as-key flag is set and the integrity of the
579 PA-SAM-CHALLENGE-2 PADATA field can be verified using the
580 sam-cksum field, then the SAD is run through the
581 string_to_key function and the result is used as the encryp-
582 tion key for the request. WARNING: the use of single-use
583 authentication data in this manner is NOT recommended unless
584 the range of the SAD is large enough to make an exhaustive
585 off-line search impractical and the risks involved in the
586 use of SAD alone are fully considered. Also, note that
587 without the availability to the KDC of a relatively static,
588 unique secret key shared with the user, the only mechanisms
592 Neuman, Zorn, Hornstein, Renard [Page 9]
598 INTERNET-DRAFT September 18, 2002
601 that can be used to protect the integrity of the PA-SAM-
602 CHALLENGE-2 PADATA field are based on either public key
603 cryptography or the KDC's a priori knowledge of the SAD
604 itself. In the latter case, the client must obtain the SAD
605 from the user and use it to verify the integrity of the
606 challenge before the new KRB_AS_REQ message is sent.
608 The sam-pk-for-sad field is reserved for future use. If
609 this field is not empty and the client does not support the
610 use of public-key encryption for SAD (to be defined in a
611 separate document), the client will not be able to complete
612 the authentication and must notify the user.
614 5.3 SAM-RESPONSE PA-DATA
616 The client will then send another KRB_AS_REQ message to the KDC,
617 but with a padata field with padata-type equal to PA-SAM-RESPONSE-2
618 and padata-value defined as follows:
620 PA-SAM-RESPONSE-2 ::= SEQUENCE {
621 sam-type[0] INTEGER,
622 sam-flags[1] SAMFlags,
623 sam-track-id[2] GeneralString OPTIONAL,
624 sam-enc-nonce-or-sad[3] EncryptedData
625 -- PA-ENC-SAM-RESPONSE-ENC,
626 sam-nonce[4] INTEGER,
627 ...
628 }
630 PA-ENC-SAM-RESPONSE-ENC ::= SEQUENCE {
631 sam-nonce[0] INTEGER,
632 sam-sad[1] GeneralString OPTIONAL,
633 ...
634 }
636 The source of the data included in the PA-SAM-RESPONSE-2 structure
637 depends upon whether or not a KRB_ERROR message was received by the
638 client from the KDC.
640 5.3.1 SAM-TYPE, SAM-FLAGS, and SAM-NONCE Fields
642 If an error reply was received, the sam-type, sam-flags, and sam-
643 nonce fields will contain copies of the same fields from the error
644 message.
646 If no error reply was received (i.e., the client knows that a
647 single-use authentication mechanism is to be used), the sam-type
648 field must be set to a value chosen from the list of registered
649 sam-type codes.
651 The value of the sam-flags field may vary depending upon the type
652 of SAM in use, but in all cases the must-pk-encrypt-sad flag must
653 be zero. If the send-encrypted-sad flag is set, the sam-sad field
654 must contain the entered single-use authentication data (see
658 Neuman, Zorn, Hornstein, Renard [Page 10]
664 INTERNET-DRAFT September 18, 2002
667 Section 5.3.3).
669 5.3.2 SAM-TRACK-ID Field
671 Note that is there is no sam-track-id in the request, it should be
672 omitted in the response. Otherwise, the sam-track-id data must be
673 copied from the SAM-CHALLENGE-2 to the SAM-RESPONSE-2.
675 5.3.3 SAM-ENC-NONCE-OR-SAD
677 The sam-enc-nonce-or-sad field represends the results of the preau-
678 thentication process. It contains the encrypted SAD or a SAD-
679 encrypted nonce. The PA-ENC-SAM-RESPONSE-ENC message is encrypted
680 with the SAD, password + SAD, or password (based on the sam-flags)
681 with key usage 27. The fields of the PA-ENC-SAM-REPONSE-ENC mes-
682 sage are populated as follows:
684 The sam-nonce contains the nonce from the SAM-CHALLENGE-2. This is
685 the same as the unencrypted sam-nonce described in section 5.2.2.
687 The sam-sad field contains the SAD if send-encrypted-sad is set in
688 the sam-flags. Otherwise, it is omitted.
690 5.4 Verification of the SAM-RESPONSE-2
692 Upon receipt the KDC validates this PADATA in much the same way
693 that it validates the PA-ENC-TS preauthentication method except
694 that it uses the SAD (if available, and possibly in conjunction
695 with saved state information or portions of the preauthentication
696 data) to determine the correct key(s) required to verify the
697 encrypted data. Note that if the KDC uses the sam-track-id field
698 to encode its state, the SAM-verification routine is responsible
699 for including information in that field to detect modification or
700 replay by an attacker.
702 5.5 KRB5-AS-REP
704 The rest of the processing of the request proceeds normally, except
705 that instead of being encrypted in the user's secret key, the
706 KRB_AS_REP message is encrypted in the key obtained above. Note,
707 however, that some single-use authentication mechanisms may require
708 further KRB_AS_REQ/KRB_ERROR exchanges to complete authentication;
709 for example, in order to allow the server to resynchronize with the
710 drifting clock on a time-based token card. In these cases the KDC
711 may respond with another KRB_ERROR message containing a different
712 sam-type value, along with appropriate prompts and/or challenges.
713 This sequence of exchanges will continue until authentication
714 either succeeds or fails.
716 6. Requirements for Single-use Authentication Mechanisms
718 Single-Use Authentication Mechanisms vary in their capabilities.
719 To aid implementers, we summarize here how various types of SAMs
720 would operate using this protocool.
724 Neuman, Zorn, Hornstein, Renard [Page 11]
730 INTERNET-DRAFT September 18, 2002
733 If a SAM system can provide a SAD or a sequence of valid SADs to
734 the KDC, then the implementation should NOT set the send-
735 encrypted-sad flag. This SAM system should provide the SAD to the
736 KDC, which will combine it with the user's long-term key (password)
737 to generate the key used to generate the checksum placed in the
738 sam-cksum field in the PA-SAM-CHALLENGE-2 message. This combined
739 key will also be used by the KDC to verify PA-SAM-RESPONSE-2 mes-
740 sage by using it to decrypt the sam-enc-nonce-or-sad field and as
741 the key to encrypt the KRB-AS-REP. If a SAM system returns a range
742 of valid responses, each response can be used to generate a valid
743 checksum which can be placed in the sam-cksum sequence.
745 If a SAM system can generate enough entropy, it can set the use-
746 sad-as-key field to use the SAD solely as keying material, but it
747 should be noted that most SAM systems that require the user to
748 enter in a response do not have enough entropy to replace the
749 user's long-term key. The most likely consumer of use-sad-as-key
750 is a hardware token which communicates a key directly with Kerberos
751 client software. With or without the use of use-sad-as-key, this
752 is the preferred method as it protects against offline dictionary
753 attacks against the user's password.
755 If a SAM system cannot provide a SAD or a sequence of SADs to the
756 KDC, then the send-encrypted-sad flag must be set. In this case,
757 the SAD will be encrypted using the user's long-term key in the
758 PA-SAM-RESPONSE-2 message. It should be noted that this is a
759 weaker solution, as it does not protect the user's password against
760 offline dictionary attacks, and any additional entropy provided by
761 the SAM system cannot be used.
763 7. Security considerations
765 Single-use authentication mechanisms requiring the use of the
766 send-encrypted-sad option are discouraged as their use on the net-
767 work is less secure than the case where a combination of the users
768 password and SAD is used as the encryption key. In particular,
769 when the send-encrypted-sad option is used, an attacker who
770 observes the response and is in possession of the users' secret key
771 (which doesn't change from login to login) can use the key to
772 decrypt the response and obtain the single-use authentication data.
773 This is dependent on the SAM technology used.
775 If the KDC sets the must-pk-encrypt-sad flag of the sam-flags field
776 but the client software being used does not support public-key
777 cryptography, it is possible that legitimate users may be denied
778 service.
780 An attacker in possession of the users encryption key (again, which
781 doesn't change from login to login) might be able to
782 generate/modify a SAM challenge and attach the appropriate check-
783 sum. This affects the security of both the send-encrypted-sad
784 option and the must-pk-encrypt-sad option.
790 Neuman, Zorn, Hornstein, Renard [Page 12]
796 INTERNET-DRAFT September 18, 2002
799 8. Expiration
800 This Internet-Draft expires on December 22, 2002.
803 9. References
805 [RFC1510]
806 The Kerberos Network Authentication System; Kohl and Neuman;
807 September 1993.
809 [RFC1760]
810 The S/Key One-Time Password System; Haller; February 1995
812 [RFC1636]
813 Report of IAB Workshop on Security in the Internet Architec-
814 ture; Braden, Clark, Crocker and Huitema; June 1994
816 [KCRYPTO]
817 Encryption and Checksum Specifications for Kerberos 5; Rae-
818 burn; May 2002
856 Neuman, Zorn, Hornstein, Renard [Page 13]
862 INTERNET-DRAFT September 18, 2002
865 10. Authors' Addresses
866 B. Clifford Neuman
867 USC/Information Sciences Institute
868 4676 Admiralty Way #1001
869 Marina del Rey, CA 90292-6695
871 Phone: 310-822-1511
872 EMail: bcn@isi.edu
875 Glen Zorn
876 Cisco Systems
877 500 108th Ave NE
878 Suite 500
879 Bellevue, WA 98004
881 Phone: 425-344-8113
882 EMail: gwz@cisco.com
885 Ken Hornstein
886 Naval Research Laboratory
887 4555 Overlook Avenue
888 Washington, DC 20375
890 Phone: 202-404-4765
891 EMail: kenh@cmf.nrl.navy.mil
894 Ken Renard
895 WareOnEarth
896 6849 Old Dominion Dr, Suite 365
897 Annandale, VA 22003
899 Phone: 703-622-3469
900 EMail: kdrenard@wareonearth.com
922 Neuman, Zorn, Hornstein, Renard [Page 14]
928 INTERNET-DRAFT September 18, 2002
931 Appendix A - Key combination algorithm
933 Definitions:
935 DR - generate "random" data from an encryption key (defined in
936 [KCRYPTO])
938 n-fold - "stretches" or "shrinks" a sequence bits to a specified
939 size (defined in [KCRYPTO])
941 random-to-key - Generates an encryption key from random input
942 (defined in [KCRYPTO])
944 DK - Derive-Key, defined in [KCRYPTO])
946 CombineConstant - The ASCII encoding of the string "combine", which
947 is defined as the following byte string:
949 { 0x63 0x6f 0x6d 0x62 0x69 0x6e 0x65 }
951 Note: | means "concatenate"
953 Given two input keys, K1 and K2, the Combine-Key function is as
954 follows:
956 R1 = DR(K1, n-fold(K2)) R2 = DR(K2, n-fold(K1))
958 rnd = n-fold(R1 | R2)
960 tkey = random-to-key(rnd)
962 Combine-Key(K1, K2) = DK(tkey, CombineConstant)
988 Neuman, Zorn, Hornstein, Renard [Page 15]