1 INTERNET-DRAFT Ken Hornstein
2 <draft-ietf-krb-wg-kerberos-sam-02.txt> Naval Research Laboratory
3 Updates: RFC 1510 Ken Renard
4 October 27, 2003 WareOnEarth
12 Integrating Single-use Authentication Mechanisms with Kerberos
15 0. Status Of this Memo
16 This document is an Internet-Draft and is subject to all provisions
17 of Section 10 of RFC2026. Internet-Drafts are working documents of
18 the Internet Engineering Task Force (IETF), its areas, and its
19 working groups. Note that other groups may also distribute working
20 documents as Internet-Drafts.
22 Internet-Drafts are draft documents valid for a maximum of six
23 months and may be updated, replaced, or obsoleted by other docu-
24 ments at any time. It is inappropriate to use Internet-Drafts as
25 reference material or to cite them other than as ``work in pro-
28 To learn the current status of any Internet-Draft, please check the
29 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha-
30 dow Directories on ds.internic.net (US East Coast), nic.nordu.net
31 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
34 The distribution of this memo is unlimited. It is filed as
35 <draft-ietf-krb-wg-kerberos-sam-02.txt>, and expires April 27,
36 2004. Please send comments to the authors.
40 This document defines extensions to the Kerberos protocol specifi-
41 cation [RFC1510] which provide a method by which a variety of
42 single-use authentication mechanisms may be supported within the
43 protocol. The method defined specifies a standard fashion in which
44 the preauthentication data and error data fields in Kerberos mes-
45 sages may be used to support single-use authentication mechanisms.
49 To simplify the following discussion, we will define those terms
50 which may be unfamiliar to the audience or specific to the discus-
53 Single-use Preauthentication Data (SPD): Data sent in the padata-
54 value field of a Kerberos V5 message proving that knowledge of
58 Hornstein, Renard, Newman, Zorn [Page 1]
64 INTERNET-DRAFT October 27, 2003
67 certain unique information is held by a principal. This informa-
68 tion may or may not be identical to the single-use authentication
69 data input to the client. For example, in the case of S/Key, the
70 principal might input a one-time password (in any of several
71 forms); the knowledge of this one-time password is taken to indi-
72 cate knowledge of the principal's secret passphrase. Similarly,
73 the SPD may or may not contain the provided single-use authentica-
74 tion data. For instance, if a given single-use authentication
75 mechanism includes a token which generates an encryption key for a
76 supported cryptosystem, that key could be used to encrypt portions
77 of the SPD before transmission. As long as the verification pro-
78 cess of the mechanism was capable of independently generating the
79 same key, the successful decryption of the SPD would provide
80 assurance that the originator of the message was in possession of
81 the token, as well as whatever information the token required to
82 generate the encryption key.
84 Single-use Authentication Mechanism (SAM): A system for generating
85 and verifying authentication data which is usable only once.
87 Single-use Authentication Data (SAD): SAM-specific data provided
88 by a principal as input to client software to be used in the crea-
92 3. Motivation and Scope
93 Several single-use authentication mechanisms are currently in
94 widespread use, including hardware-based schemes from vendors such
95 as Enigma Logic, CRYPTOCard, and Security Dynamics and software-
96 based methods like S/Key [RFC1760]. The hardware-based schemes
97 typically require that the authenticating user carry a small,
98 credit-card-sized electronic device (called a token) which is used
99 to generate unique authentication data. Some tokens require the
100 user to enter data into the device. This input may take the form
101 of a Personal Identification Number (PIN), a server-generated chal-
102 lenge string or both. Other tokens do not use a challenge-response
103 technique, instead spontaneously generating new and unique authen-
104 tication data every few seconds. These tokens are usually time-
105 synchronized with a server. The use of one-time passwords and
106 token cards as an authentication mechanism has steadily increased
107 over the past few years; in addition, the Internet Architecture
108 Board has encouraged the use of SAMs to improve Internet security
111 The widespread acceptance of Kerberos within the Internet community
112 has produced considerable demand for the integration of SAM tech-
113 nology with the authentication protocol. Several currently avail-
114 able implementations of Kerberos include support for some types of
115 token cards, but the implementations are either not interoperable,
116 or would require the release of source code (not always an option)
117 to make them interoperate. This memo attempts to remedy that prob-
118 lem by specifying a method in which SAM data may be securely tran-
119 sported in Kerberos V5 messages in a standard, extensible fashion.
120 This document does not, however, attempt to precisely specify
124 Hornstein, Renard, Newman, Zorn [Page 2]
130 INTERNET-DRAFT October 27, 2003
133 either the generation or verification of SAM data, since this is
134 likely to be SAM-specific; nor does it dictate the conditions under
135 which SAM data must be included in Kerberos messages, since we con-
136 sider this to be a matter of local policy.
138 A primary reason for using a SAM with Kerberos is to reduce the
139 threat from common attacks on Kerberos passwords (poorly chosen
140 passwords, password guessing, etc). If passwords are used in com-
141 bination with SAM authentication data, users must still adhere to
142 sensible password policies and safe practices regarding the selec-
143 tion, secrecy, and maintenance of their passwords. Depending on
144 the specific mechanism used, the purpose of the SAD is to augment
145 (or sometimes replace) the use of a password as a secret key.
148 4. Generic Approach - Two Models
149 As outlined above, there are essentially two types of single-use
150 authentication mechanisms: challenge/response and time-based. In
151 order to support challenge/response mechanisms, the Kerberos Key
152 Distribution Center (KDC) must communicate the appropriate chal-
153 lenge string to the user, via the client software. Furthermore,
154 some challenge/response mechanisms require tight synchronization
155 between all instances of the KDC and the client. One example is
156 S/Key and its variants. If the KDC and client do not perform the
157 same number of message digest iterations, the protocol will fail;
158 worse, it might be possible for an eavesdropping attacker to cap-
159 ture a valid S/Key passcode and replay it to a KDC replica which
160 had an outdated iteration number. In the time-based case, no chal-
161 lenge is required. This naturally gives rise to two modes of
162 client behavior, described below.
165 4.1 Challenge/Response Model
166 The client begins with an initial KRB_AS_REQ message to the KDC,
167 possibly using existing preauthentication methods (PA-ENC-TIMESTAMP
168 (encrypted timestamp), PA-OSF-DCE (DCE), etc.). Depending on
169 whether preauthentication is used, the user may or may not be
170 prompted at this time for a Kerberos password. If (for example)
171 encrypted timestamp preauthentication is used, then the user will
172 be prompted; on the other hand, if no preauthentication is in use
173 the prompt for the password may be deferred (possibly forever).
174 Note that the use of preauthentication here may allow an offline
175 guessing attack against the Kerberos password separate from the
176 SPD. However, if the use of a SAM is required, then the password
177 by itself is not sufficient for authentication. (Specify character
180 The KDC will determine in an implementation- and policy-dependent
181 fashion if the client is required to utilize a single-use authenti-
182 cation mechanism. For example, the implementation may use IP
183 address screening to require principals authenticating from outside
184 a firewall to use a SAM, while principals on the inside need not.
185 If SAM usage is required, then the KDC will respond with a
186 KRB_ERROR message, with the error-code field set to
190 Hornstein, Renard, Newman, Zorn [Page 3]
196 INTERNET-DRAFT October 27, 2003
199 KDC_ERR_PREAUTH_REQUIRED and the e-data field containing the ASN.1
200 structure that is a sequence of PA-DATA fields.
202 If the type of one of the PA-DATA fields is PA-SAM-REDIRECT, the
203 client should re-execute the authentication protocol from the
204 beginning, directing messages to another of the KDCs for the realm.
205 This is done to allow some methods to require that a single KDC be
206 used for SAM authentication when tight synchronization is needed
207 between all replicas and the KDC database propagation code does not
208 provide such synchronization. The corresponding padata-value will
209 contain an encoded sequence of host addresses [RFC1510], from which
210 the client must choose the KDC to be contacted next. The PA-SAM-
211 REDIRECT is defined as:
214 PA-SAM-REDIRECT ::= HostAddresses
217 Client implementations SHOULD check the addresses in the PA-SAM-
218 REDIRECT and verify that they are a subset of the KDC addresses
219 that they have been configured for that realm.
221 If none of the PA-DATA fields have a value of PA-SAM-REDIRECT, then
222 if one of the PA-DATA fields has the type PA-SAM-CHALLENGE-2, the
223 exchange will continue as described in section 5, below.
225 Note that some Kerberos implementations support an older preauthen-
226 tication mechanism with the padata types PA-SAM-CHALLENGE and PA-
227 SAM-RESPONSE. That protocol is depreciated and not defined here.
231 For mechanisms where no challenge is required, the user (or the
232 client software being utilized) may or may not know a priori
233 whether SAM usage is required. If it does not know, then the ini-
234 tial exchange may proceed as above. If it is known that a use of a
235 single-use authentication mechanism is required then the first
236 exchange can be skipped and the authentication will continue as
240 5. SAM Preauthentication
242 An optional SAM-CHALLENGE-2 may be sent from the KDC to the client
243 and the client will send a SAM-RESPONSE-2 as pre-authentication
244 data in the KRB-AS-REQ. The details of the messages follow.
248 Prior to performing preauthentication using a single-use authenti-
249 cation mechanism, the client must know whether a challenge is
250 required (if the client doesn't have this information prior to its
251 sending the first KRB_AS_REQ message, it will be informed of the
252 requirement by the KDC, as described in section 4.1). The client
256 Hornstein, Renard, Newman, Zorn [Page 4]
262 INTERNET-DRAFT October 27, 2003
265 does NOT need to know the specific type of SAM in use. If a chal-
266 lenge is required the client will be sent the challenge by the KDC.
267 This means that a client supporting SAMs will be able to work with
268 new methods without modification. The challenge, as well as all
269 other prompts mentioned herein, can be internationalized by the KDC
270 on a per-principal basis.
272 If a KRB_ERROR message is received from the KDC indicating that SAM
273 usage is required, that message will include in its e-data field a
274 PA-DATA structure that encodes information about the SAM to be
275 used. This includes whether a challenge is required, and if so,
276 the challenge itself; and informational data about the type of SAM
277 that is in use, and how to prompt for the SAD. The SAM type is
278 informational only and does not affect the behavior of the client.
279 The prompt is also informational and may be presented to the user
280 by the client, or it may be safely ignored.
282 The ASN.1 definition for the SAM challenge is:
284 PA-SAM-CHALLENGE-2 ::= SEQUENCE {
285 sam-body[0] PA-SAM-CHALLENGE-2-BODY,
286 sam-cksum[1] SEQUENCE (1..MAX) OF Checksum,
290 PA-SAM-CHALLENGE-2-BODY ::= SEQUENCE {
291 sam-type[0] INTEGER (0..4294967295),
292 sam-flags[1] SAMFlags,
293 sam-type-name[2] GeneralString OPTIONAL,
294 sam-track-id[3] GeneralString OPTIONAL,
296 sam-challenge-label[4] GeneralString OPTIONAL,
297 sam-challenge[5] GeneralString OPTIONAL,
298 sam-response-prompt[6] GeneralString OPTIONAL,
299 sam-pk-for-sad[7] OCTET STRING OPTIONAL,
300 sam-nonce[8] INTEGER (0..4294967295),
301 sam-etype[9] INTEGER (0..4294967295),
305 SAMFlags ::= BIT STRING (SIZE (32..MAX))
307 -- send-encrypted-sad(1)
308 -- must-pk-encrypt-sad(2)
310 5.1.1 SAM-TYPE and SAM-TYPE-NAME Fields
312 The sam-type field is informational only, but it must be specified
313 and sam-type values must be registered with the IANA.
315 Initially defined values of the sam-type codes are:
317 PA_SAM_TYPE_ENIGMA 1 -- Enigma Logic
318 PA_SAM_TYPE_DIGI_PATH 2 -- Digital Pathways
322 Hornstein, Renard, Newman, Zorn [Page 5]
328 INTERNET-DRAFT October 27, 2003
331 PA_SAM_TYPE_SKEY_K0 3 -- S/key where KDC has key 0
332 PA_SAM_TYPE_SKEY 4 -- Traditional S/Key
333 PA_SAM_TYPE_SECURID 5 -- Security Dynamics
334 PA_SAM_TYPE_CRYPTOCARD 6 -- CRYPTOCard
336 PA_SAM_TYPE_SECURID, PA_SAM_TYPE_DIGI_PATH, PA_SAM_TYPE_ENIGMA, and
337 PA_SAM_TYPE_CRYPTOCARD represent popular token cards.
338 PA_SAM_TYPE_SKEY is the traditional S/Key protocol, in which the
339 SAD verifier does not have knowledge of the principal's S/Key
340 secret. PA_SAM_TYPE_SKEY_K0 is a variant of S/Key that uses the
341 same SAD and PC software or hardware device, but where the zeroth
342 key (the S/Key secret) is actually stored on, and can be used by,
343 the SAD verifier to independently generate the correct authentica-
346 Note that using PA_SAM_TYPE_SKEY_K0 gives up one advantage of
347 S/Key, viz., that the information required to generate the SAD need
348 not be stored on the host; but since the SAD verifier (which may be
349 the KDC) is assumed to be more secure than other hosts on the net-
350 work, it may be acceptable to give up this advantage in some situa-
351 tions. The advantage of using this S/Key variant is that the secu-
352 rity of the network protocol is strengthened since the SAD need not
353 be sent from the client to the KDC. Thus, the SAD can be used as
354 part of the key used to encrypt the encrypted parts of both the SPD
355 and the KRB_AS_REP message, rather than being sent protected by the
356 principal's Kerberos secret key which may have been previously
357 exposed to an attacker (see section 6, below). In any case, there
358 is a definite advantage to being interoperable with the S/Key algo-
361 Due to the volatility of, and rapid developments in, the area of
362 single-use authentication mechanisms (both software-only and
363 hardware supported), any subsequently defined sam-type codes will
364 be maintained by the IANA.
366 The optional sam-type-name field is a UTF-8 character string for
367 informational use only. It may be used by the client to display a
368 short description of the type of single-use authentication mechan-
371 5.1.2 SAM-FLAGS Field
373 The sam-flags field indicates whether the SAD is known by the KDC
374 (in which case it can be used as part of the encryption key for the
375 ensuing KRB_AS_REP message), or if it must be provided to the KDC
376 in a recoverable manner. If it is known to the KDC, use-sad-as-key
377 indicates that the SAD alone will be used to generate the encryp-
378 tion key for the forthcoming KRB_AS_REQ and KRB_AS_REP messages,
379 and that the user will not need to also enter a password. We
380 recommend that this option only be used if the SAD will be used to
381 generate adequate keying material (sufficient length, secrecy, ran-
382 domness) for the cryptographic algorithm used. If the single-use
383 authentication data is not known (and cannot be generated or
384 discovered) by the KDC, then send-encrypted-sad flag will be set,
388 Hornstein, Renard, Newman, Zorn [Page 6]
394 INTERNET-DRAFT October 27, 2003
397 indicating that the SAD must be sent to the KDC encrypted under the
398 principal's secret key. If neither use-sad-as-key nor send-
399 encrypted-sad are set, the client may assume that the KDC knows the
400 SAD, but the Kerberos password should be used along with the
401 passcode in the derivation of the encryption key (see below). No
402 more than one of the send-encrypted-sad and use-sad-as-key flags
403 should be in a SAM-CHALLENGE-2.
405 The must-pk-encrypt-sad flag is reserved for future use. If this
406 flag is set and a client does not support the must-pk-encrypt-sad
407 option (to be defined in a separate document), the client will not
408 be able to complete the authentication and must notify the user.
410 5.1.3 SAM-CHECKSUM Field
412 The sam-cksum field contains a sequence of at least one crypto-
413 graphic checksum of encoding of the PA-SAM-CHALLENGE-2 sequence.
414 If the send-encrypted-sad flag is set, the key to be used for this
415 checksum is the client's long-term secret. If the use-sad-as-key
416 flag is set, then the SAD alone will be used as the key. If nei-
417 ther flag is set, then the key used for this checksum is derived
418 from the SAD and the user's password (see section 5.2).
420 The checksum algorithm to be used for this is the mandatory check-
421 sum associated with the encryption algorithm specified in the sam-
422 etype field, with a key usage of 25.
424 In some cases there may be more than one valid SAD; some preauthen-
425 tication mechanisms may have a range of valid responses. In that
426 case, the KDC may elect to return multiple checksums, one for each
427 possible SAD response. The number of possible responses of course
428 depends on the mechanism and site policy. In the case where multi-
429 ple checksums are returned, the client MUST try each checksum in
430 turn until one of the checksums is verified successfully. Note
431 that in the non-send-encrypted-sad case the checksum cannot be ver-
432 ified until the user enters in the SAD, but if no checksum can be
433 verified, the client MUST not send a response but instead return an
436 The sam-cksum field is generated by calculating the specified
437 checksum over the DER-encoded SAM-CHALLENGE-2-BODY sequence.
439 If no checksum is included, or is of the wrong type, or none are
440 found which are correct, the client MUST abort the dialogue with
441 the KDC and issue, respectively, KRB5_SAM_NO_CHECKSUM,
442 KRB5_SAM_BAD_CHECKSUM_TYPE, or KRB5_SAM_BAD_CHECKSUM error mes-
445 5.1.4 SAM-TRACK-ID Field
447 The optional sam-track-id field may be returned by the KDC in the
448 KRB_ERROR message. If present, the client MUST copy this field
449 into the corresponding field of the SAM response sent in the subse-
450 quent KRB_AS_REQ message. This field may be used by the KDC to
454 Hornstein, Renard, Newman, Zorn [Page 7]
460 INTERNET-DRAFT October 27, 2003
463 match challenges and responses. It might be a suitably encoded
464 integer, or even be encrypted data with the KDC state encoded so
465 that the KDC doesn't have to maintain the state internally. Note
466 that when a KDC supplies a sam-track-id, it MUST link the sam-
467 track-id with the sam-nonce field to prevent spoofing of the sam-
470 The key usage type 26 is reserved for use to encrypt the sam-
471 track-id data. The key used to encrypt the sam-track-id is
474 5.1.5 SAM-CHALLENGE-LABEL Field
476 The sam-challenge-label field is informational and optional. If it
477 is included, is will be an UTF-8 encoded character. If present, a
478 client may choose to precede the presentation of the challenge with
479 this string. For example, if the challenge is 135773 and the
480 string in the sam-challenge-label field is "Enter the following
481 number on your card", the client may choose to display to the user:
483 Enter the following number on your card: 135773
485 If no challenge label was presented, or if the client chooses to
486 ignore it, the client might display instead:
488 Challenge from authentication server: 135773
490 Internationalization is supported by allowing customization of the
491 challenge label and other strings on a per-principal basis. Note
492 that this character string should be encoded using UTF-8.
494 5.1.6 SAM-CHALLENGE Field
496 The optional sam-challenge field contains a string that will be
497 needed by the user to generate a suitable response. If the sam-
498 challenge field is left out, it indicates that the SAM in use does
499 not require a challenge, and that the authorized user should be
500 able to produce the correct SAD without one. If the sam-challenge
501 field is present, it is the data that is used by the SAD generator
502 to create the SAD to be used in the production of the SPD to be
503 included in the response.
505 5.1.7 SAM-RESPONSE-PROMPT Field
507 The sam-response-prompt field is informational and optional. If
508 present, a client may choose to precede the prompt for the response
509 with the specified string.
513 5.1.8 SAM-PK-FOR-SAD Field
515 sam-pk-for-sad is an optional field. It is included in the
516 interest of future extensability of the protocol to the use of
520 Hornstein, Renard, Newman, Zorn [Page 8]
526 INTERNET-DRAFT October 27, 2003
529 public-key cryptography.
531 5.1.9 SAM-NONCE Field
533 The sam-nonce is a KDC-supplied nonce and should conform to the
534 specification of the nonce field in a KRB_KDC_REQ message
537 Challenge/Response mechanisms MUST link the nonce field with the
538 sam-track-id (if one is included) to prevent replay of the sam-
541 5.1.10 SAM-ETYPE Field
543 The sam-etype field contains the encryption type to be used by the
544 client for all encrypted fields in the PA-SAM-RESPONSE-2 message.
545 The KDC should pick an appropriate encryption algorithm based on
546 the encryption algorithms listed in the client's initial
549 5.2 Obtaining SAM Authentication Data
551 If the client is performing SAM preauthentication in the initial
552 message, without receipt of a PA-SAM-CHALLENGE-2 (i.e. without
553 waiting for the KRB_ERROR message), and the SAM in use does not
554 require a challenge, the client will prompt for the SAD in an
555 application-specific manner.
557 Once the user has been prompted for and entered the SAD (and possi-
558 bly the Kerberos password), the client will derive a key to be used
559 to encrypt the preauthentication data for a KRB_AS_REQ message.
560 This key will be determined as follows:
562 By default, the key is derived from the password and the SAD
563 by running each through the string_to_key function [RFC1510]
564 separately; i.e., K1 = string_to_key(password) and K2 =
565 string_to_key(SAD). When the keys are both DES or 3DES,
566 keys K1 and K2 will be combined using the algorithm
567 described in Appendix B, ``DES/3DES Key Combination Algo-
568 rithm''. For all other encryption algorithms, the algorithm
569 described in Appendix A, ``Key Combination Algorithm'' shall
570 be used. Note that this algorithm is not commutative; an
571 implementation MUST insure that K1 is the key corresponding
572 to the user's long-term password, and K2 is the output from
573 the SAD. In either case, the salt used by the string_to_key
574 algorithm for the SAD shall be the same salt as used for the
577 If the send-encrypted-sad flag is set, the key will be
578 derived by running the Kerberos password though the
579 string_to_key function in the normal fashion.
581 If the use-sad-as-key flag is set and the integrity of the
582 PA-SAM-CHALLENGE-2 PADATA field can be verified using the
586 Hornstein, Renard, Newman, Zorn [Page 9]
592 INTERNET-DRAFT October 27, 2003
595 sam-cksum field, then the SAD is run through the
596 string_to_key function and the result is used as the encryp-
597 tion key for the request. WARNING: the use of single-use
598 authentication data in this manner is NOT recommended unless
599 the range of the SAD is large enough to make an exhaustive
600 off-line search impractical and the risks involved in the
601 use of SAD alone are fully considered. Also, note that
602 without the availability to the KDC of a relatively static,
603 unique secret key shared with the user, the only mechanisms
604 that can be used to protect the integrity of the PA-SAM-
605 CHALLENGE-2 PADATA field are based on either public key
606 cryptography or the KDC's a priori knowledge of the SAD
607 itself. In the latter case, the client must obtain the SAD
608 from the user and use it to verify the integrity of the
609 challenge before the new KRB_AS_REQ message is sent.
611 The sam-pk-for-sad field is reserved for future use. If
612 this field is not empty and the client does not support the
613 use of public-key encryption for SAD (to be defined in a
614 separate document), the client will not be able to complete
615 the authentication and must notify the user.
617 5.3 SAM-RESPONSE PA-DATA
619 The client will then send another KRB_AS_REQ message to the KDC,
620 but with a padata field with padata-type equal to PA-SAM-RESPONSE-2
621 and padata-value defined as follows:
623 PA-SAM-RESPONSE-2 ::= SEQUENCE {
624 sam-type[0] INTEGER (0..4294967295),
625 sam-flags[1] SAMFlags,
626 sam-track-id[2] GeneralString OPTIONAL,
627 sam-enc-nonce-or-sad[3] EncryptedData,
628 -- PA-ENC-SAM-RESPONSE-ENC
630 sam-nonce[4] INTEGER (0..4294967295),
634 PA-ENC-SAM-RESPONSE-ENC ::= SEQUENCE {
635 sam-nonce[0] INTEGER (0..4294967295),
636 sam-sad[1] GeneralString OPTIONAL,
640 The source of the data included in the PA-SAM-RESPONSE-2 structure
641 depends upon whether or not a KRB_ERROR message was received by the
644 5.3.1 SAM-TYPE, SAM-FLAGS, and SAM-NONCE Fields
646 If an error reply was received, the sam-type, sam-flags, and sam-
647 nonce fields will contain copies of the same fields from the error
652 Hornstein, Renard, Newman, Zorn [Page 10]
658 INTERNET-DRAFT October 27, 2003
661 If no error reply was received (i.e., the client knows that a
662 single-use authentication mechanism is to be used), the sam-type
663 field must be set to a value chosen from the list of registered
666 The value of the sam-flags field may vary depending upon the type
667 of SAM in use, but in all cases the must-pk-encrypt-sad flag must
668 be zero. If the send-encrypted-sad flag is set, the sam-sad field
669 must contain the entered single-use authentication data (see Sec-
672 5.3.2 SAM-TRACK-ID Field
674 Note that if there is no sam-track-id in the request, it MUST be
675 omitted in the response. Otherwise, the sam-track-id data MUST be
676 copied from the SAM-CHALLENGE-2 to the SAM-RESPONSE-2.
678 5.3.3 SAM-ENC-NONCE-OR-SAD
680 The sam-enc-nonce-or-sad field represends the results of the preau-
681 thentication process. It contains the encrypted SAD or a SAD-
682 encrypted nonce. The PA-ENC-SAM-RESPONSE-ENC message is encrypted
683 with the SAD, password + SAD, or password (based on the sam-flags)
684 with key usage 27. The fields of the PA-ENC-SAM-REPONSE-ENC mes-
685 sage are populated as follows:
687 The sam-nonce contains the nonce from the SAM-CHALLENGE-2. This is
688 the same as the unencrypted sam-nonce described in section 5.2.2.
690 The sam-sad field contains the SAD if send-encrypted-sad is set in
691 the sam-flags. Otherwise, it is omitted.
693 5.4 Verification of the SAM-RESPONSE-2
695 Upon receipt the KDC validates this PADATA in much the same way
696 that it validates the PA-ENC-TS preauthentication method except
697 that it uses the SAD (if available, and possibly in conjunction
698 with saved state information or portions of the preauthentication
699 data) to determine the correct key(s) required to verify the
700 encrypted data. Note that if the KDC uses the sam-track-id field
701 to encode its state, the SAM-verification routine is responsible
702 for including information in that field to detect modification or
703 replay by an attacker.
707 The rest of the processing of the request proceeds normally, except
708 that instead of being encrypted in the user's secret key, the
709 KRB_AS_REP message is encrypted in the key obtained above. Note,
710 however, that some single-use authentication mechanisms may require
711 further KRB_AS_REQ/KRB_ERROR exchanges to complete authentication;
712 for example, in order to allow the server to resynchronize with the
713 drifting clock on a time-based token card. In these cases the KDC
714 may respond with another KRB_ERROR message containing a different
718 Hornstein, Renard, Newman, Zorn [Page 11]
724 INTERNET-DRAFT October 27, 2003
727 sam-type value, along with appropriate prompts and/or challenges.
728 This sequence of exchanges will continue until authentication
729 either succeeds or fails.
731 6. Requirements for Single-use Authentication Mechanisms
733 Single-Use Authentication Mechanisms vary in their capabilities.
734 To aid implementers, we summarize here how various types of SAMs
735 would operate using this protocool.
737 If a SAM system can provide a SAD or a sequence of valid SADs to
738 the KDC, then the implementation SHOULD NOT set the send-
739 encrypted-sad flag. This SAM system should provide the SAD to the
740 KDC, which will combine it with the user's long-term key (password)
741 to generate the key used to generate the checksum placed in the
742 sam-cksum field in the PA-SAM-CHALLENGE-2 message. This combined
743 key will also be used by the KDC to verify PA-SAM-RESPONSE-2 mes-
744 sage by using it to decrypt the sam-enc-nonce-or-sad field and as
745 the key to encrypt the KRB-AS-REP. If a SAM system returns a range
746 of valid responses, each response can be used to generate a valid
747 checksum which can be placed in the sam-cksum sequence.
749 If a SAM system can generate enough entropy, it can set the use-
750 sad-as-key field to use the SAD solely as keying material, but it
751 should be noted that most SAM systems that require the user to
752 enter in a response do not have enough entropy to replace the
753 user's long-term key. The most likely consumer of use-sad-as-key
754 is a hardware token which communicates a key directly with Kerberos
755 client software. With or without the use of use-sad-as-key, this
756 is the preferred method as it protects against offline dictionary
757 attacks against the user's password.
759 If a SAM system cannot provide a SAD or a sequence of SADs to the
760 KDC, then the send-encrypted-sad flag must be set. In this case,
761 the SAD will be encrypted using the user's long-term key in the
762 PA-SAM-RESPONSE-2 message. It should be noted that this is a
763 weaker solution, as it does not protect the user's password against
764 offline dictionary attacks, and any additional entropy provided by
765 the SAM system cannot be used.
767 7. Security considerations
769 Single-use authentication mechanisms requiring the use of the
770 send-encrypted-sad option are discouraged as their use on the net-
771 work is less secure than the case where a combination of the users
772 password and SAD is used as the encryption key. In particular,
773 when the send-encrypted-sad option is used, an attacker who
774 observes the response and is in possession of the users' secret key
775 (which doesn't change from login to login) can use the key to
776 decrypt the response and obtain the single-use authentication data.
777 This is dependent on the SAM technology used.
779 If the KDC sets the must-pk-encrypt-sad flag of the sam-flags field
780 but the client software being used does not support public-key
784 Hornstein, Renard, Newman, Zorn [Page 12]
790 INTERNET-DRAFT October 27, 2003
793 cryptography, it is possible that legitimate users may be denied
796 An attacker in possession of the users encryption key (again, which
797 doesn't change from login to login) might be able to
798 generate/modify a SAM challenge and attach the appropriate check-
799 sum. This affects the security of both the send-encrypted-sad
800 option and the must-pk-encrypt-sad option.
804 This Internet-Draft expires on April 27, 2004.
810 The Kerberos Network Authentication System; Kohl and Neuman;
814 The S/Key One-Time Password System; Haller; February 1995
817 Report of IAB Workshop on Security in the Internet Architec-
818 ture; Braden, Clark, Crocker and Huitema; June 1994
821 Encryption and Checksum Specifications for Kerberos 5; Rae-
850 Hornstein, Renard, Newman, Zorn [Page 13]
856 INTERNET-DRAFT October 27, 2003
859 10. Authors' Addresses
861 Naval Research Laboratory
866 EMail: kenh@cmf.nrl.navy.mil
871 6849 Old Dominion Dr, Suite 365
875 EMail: kdrenard@wareonearth.com
879 USC/Information Sciences Institute
880 4676 Admiralty Way #1001
881 Marina del Rey, CA 90292-6695
916 Hornstein, Renard, Newman, Zorn [Page 14]
922 INTERNET-DRAFT October 27, 2003
925 Appendix A - Key combination algorithm
929 prf - Pseudo-random function that outputs an octet string based on
930 an input key and a input octet string (defined in [KCRYPTO])
932 ^ - Exclusive-OR operation
934 random-to-key - Generates an encryption key from random input
935 (defined in [KCRYPTO])
937 Given two input keys, K1 and K2, where K1 is derived from the
938 user's long-term password, and K2 is derived from the SAD, output
939 key (K3) is derived as follows:
941 Two sequence of octets, R1 and R2, shall be produced for each key
942 K1 and K2. R1 and R2 will be generated by iterating over calls to
943 prf() until enough bits are generated as needed by the random-to-
944 key function for the encryption type specified for K3.
946 The octet-string parameter to the prf() function shall be the ASCII
947 string "CombineA" for K1, and "CombineB" for K2. These have the
948 following byte values:
949 { 0x43 0x6f 0x6d 0x62 0x69 0x6e 0x65 0x41 }
950 { 0x43 0x6f 0x6d 0x62 0x69 0x6e 0x65 0x42 }
952 Furthermore, on each iteration both octet-strings will have
953 appended to them the iteration count in the form of an ASCII, base
954 10, numeral. The iteration count shall start at zero. The format
955 of the iteration count is equivalant to the C language "%d" format
956 to the printf() function call. Pseudo code implementing this fol-
960 while ( bits < required_bits) {
961 sprintf(A1, "CombineA%d", count);
962 sprintf(A2, "CombineB%d", count);
968 When R1 and R2 have been generated, they are truncated if the they
969 are longer than the length required by random-to-key. The key is
970 then generated as follows:
972 K3 = random-to-key(R1 ^ R2)
982 Hornstein, Renard, Newman, Zorn [Page 15]
988 INTERNET-DRAFT October 27, 2003
991 Appendix B - DES/3DES Key combination algorithm
995 DR - generate "random" data from an encryption key (defined in
998 n-fold - "stretches" or "shrinks" a sequence bits to a specified
999 size (defined in [KCRYPTO])
1001 random-to-key - Generates an encryption key from random input
1002 (defined in [KCRYPTO])
1004 DK - Derive-Key, defined in [KCRYPTO])
1006 CombineConstant - The ASCII encoding of the string "combine",
1007 which is defined as the following byte string:
1009 { 0x63 0x6f 0x6d 0x62 0x69 0x6e 0x65 }
1011 Note: | means "concatenate"
1013 Given two input keys, K1 and K2, the Combine-Key function is as
1016 R1 = DR(K1, n-fold(K2)) R2 = DR(K2, n-fold(K1))
1018 rnd = n-fold(R1 | R2)
1020 tkey = random-to-key(rnd)
1022 Combine-Key(K1, K2) = DK(tkey, CombineConstant)
1048 Hornstein, Renard, Newman, Zorn [Page 16]
git.samba.org / samba.git / blob