draft-ietf-krb-wg-kerberos-sam-01.txt   draft-ietf-krb-wg-kerberos-sam-02.txt 
INTERNET-DRAFT Ken Hornstein
INTERNET-DRAFT Clifford Neuman <draft-ietf-krb-wg-kerberos-sam-02.txt> Naval Research Laboratory
<draft-ietf-krb-wg-kerberos-sam-01.txt> ISI Updates: RFC 1510 Ken Renard
Updates: RFC 1510 Glen Zorn October 27, 2003 WareOnEarth
October 1, 2002 Cisco Systems Clifford Newman
Ken Hornstein ISI
Naval Research Laboratory Glen Zorn
Ken Renard Cisco Systems
WareOnEarth
Integrating Single-use Authentication Mechanisms with Kerberos Integrating Single-use Authentication Mechanisms with Kerberos
0. Status Of this Memo 0. Status Of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. Internet-Drafts are working documents of of Section 10 of RFC2026. Internet-Drafts are working documents of
the Internet Engineering Task Force (IETF), its areas, and its the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other docu- months and may be updated, replaced, or obsoleted by other docu-
ments at any time. It is inappropriate to use Internet-Drafts as ments at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as ``work in pro- reference material or to cite them other than as ``work in pro-
gress.'' gress.''
The list of current Internet-Drafts can be accessed at To learn the current status of any Internet-Draft, please check the
http://www.ietf.org/1id-abstracts.html ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha-
dow Directories on ds.internic.net (US East Coast), nic.nordu.net
The list of Internet-Draft Shadow Directories can be accessed at (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
http://www.ietf.org/shadow.html Rim).
The distribution of this memo is unlimited. It is filed as The distribution of this memo is unlimited. It is filed as
<draft-ietf-krb-wg-kerberos-sam-01.txt>, and expires April 2, 2003. <draft-ietf-krb-wg-kerberos-sam-02.txt>, and expires April 27,
Please send comments to the authors. 2004. Please send comments to the authors.
1. Abstract 1. Abstract
This document defines extensions to the Kerberos protocol specifi- This document defines extensions to the Kerberos protocol specifi-
cation [RFC1510] which provide a method by which a variety of cation [RFC1510] which provide a method by which a variety of
single-use authentication mechanisms may be supported within the single-use authentication mechanisms may be supported within the
protocol. The method defined specifies a standard fashion in which protocol. The method defined specifies a standard fashion in which
the preauthentication data and error data fields in Kerberos mes- the preauthentication data and error data fields in Kerberos mes-
sages may be used to support single-use authentication mechanisms. sages may be used to support single-use authentication mechanisms.
2. Terminology 2. Terminology
skipping to change at page 3, line 28 skipping to change at page 3, line 28
4. Generic Approach - Two Models 4. Generic Approach - Two Models
As outlined above, there are essentially two types of single-use As outlined above, there are essentially two types of single-use
authentication mechanisms: challenge/response and time-based. In authentication mechanisms: challenge/response and time-based. In
order to support challenge/response mechanisms, the Kerberos Key order to support challenge/response mechanisms, the Kerberos Key
Distribution Center (KDC) must communicate the appropriate chal- Distribution Center (KDC) must communicate the appropriate chal-
lenge string to the user, via the client software. Furthermore, lenge string to the user, via the client software. Furthermore,
some challenge/response mechanisms require tight synchronization some challenge/response mechanisms require tight synchronization
between all instances of the KDC and the client. One example is between all instances of the KDC and the client. One example is
S/Key and its variants. If the KDC and client do not perform the S/Key and its variants. If the KDC and client do not perform the
same number of message digest iterations, the protocol will fail; same number of message digest iterations, the protocol will fail;
worse, it might be possible for an eavesdopping attacker to capture worse, it might be possible for an eavesdropping attacker to cap-
a valid S/Key passcode and replay it to a KDC replica which had an ture a valid S/Key passcode and replay it to a KDC replica which
outdated iteration number. In the time-based case, no challenge is had an outdated iteration number. In the time-based case, no chal-
required. This naturally gives rise to two modes of client lenge is required. This naturally gives rise to two modes of
behavior, described below. client behavior, described below.
4.1 Challenge/Response Model 4.1 Challenge/Response Model
The client begins with an initial KRB_AS_REQ message to the KDC, The client begins with an initial KRB_AS_REQ message to the KDC,
possibly using existing preauthentication methods (PA-ENC-TIMESTAMP possibly using existing preauthentication methods (PA-ENC-TIMESTAMP
(encrypted timestamp), PA-OSF-DCE (DCE), etc.). Depending on (encrypted timestamp), PA-OSF-DCE (DCE), etc.). Depending on
whether preauthentication is used, the user may or may not be whether preauthentication is used, the user may or may not be
prompted at this time for a Kerberos password. If (for example) prompted at this time for a Kerberos password. If (for example)
encrypted timestamp preauthentication is used, then the user will encrypted timestamp preauthentication is used, then the user will
be prompted; on the other hand, if no preauthentication is in use be prompted; on the other hand, if no preauthentication is in use
the prompt for the password may be deferred (possibly forever). the prompt for the password may be deferred (possibly forever).
skipping to change at page 5, line 30 skipping to change at page 5, line 30
The ASN.1 definition for the SAM challenge is: The ASN.1 definition for the SAM challenge is:
PA-SAM-CHALLENGE-2 ::= SEQUENCE { PA-SAM-CHALLENGE-2 ::= SEQUENCE {
sam-body[0] PA-SAM-CHALLENGE-2-BODY, sam-body[0] PA-SAM-CHALLENGE-2-BODY,
sam-cksum[1] SEQUENCE(1..MAX) OF Checksum, sam-cksum[1] SEQUENCE(1..MAX) OF Checksum,
... ...
} }
PA-SAM-CHALLENGE-2-BODY ::= SEQUENCE { PA-SAM-CHALLENGE-2-BODY ::= SEQUENCE {
sam-type[0] INTEGER, sam-type[0] INTEGER (0..4294967295),
sam-flags[1] SAMFlags, sam-flags[1] SAMFlags,
sam-type-name[2] GeneralString OPTIONAL, sam-type-name[2] GeneralString OPTIONAL,
sam-track-id[3] GeneralString OPTIONAL, sam-track-id[3] GeneralString OPTIONAL,
-- Key usage of 26
sam-challenge-label[4] GeneralString OPTIONAL, sam-challenge-label[4] GeneralString OPTIONAL,
sam-challenge[5] GeneralString OPTIONAL, sam-challenge[5] GeneralString OPTIONAL,
sam-response-prompt[6] GeneralString OPTIONAL, sam-response-prompt[6] GeneralString OPTIONAL,
sam-pk-for-sad[7] EncryptionKey OPTIONAL, sam-pk-for-sad[7] OCTET STRING OPTIONAL,
sam-nonce[8] INTEGER, sam-nonce[8] INTEGER (0..4294967295),
sam-etype[9] INTEGER, sam-etype[9] INTEGER (0..4294967295),
... ...
} }
SAMFlags ::= BIT STRING (SIZE (32..MAX)) SAMFlags ::= BIT STRING (SIZE (32..MAX))
-- use-sad-as-key(0), -- use-sad-as-key(0)
-- send-encrypted-sad(1), -- send-encrypted-sad(1)
-- must-pk-encrypt-sad(2), -- must-pk-encrypt-sad(2)
5.1.1 SAM-TYPE and SAM-TYPE-NAME Fields 5.1.1 SAM-TYPE and SAM-TYPE-NAME Fields
The sam-type field is informational only, but it must be specified The sam-type field is informational only, but it must be specified
and sam-type values must be registered with the IANA. and sam-type values must be registered with the IANA.
Initially defined values of the sam-type codes are: Initially defined values of the sam-type codes are:
PA_SAM_TYPE_ENIGMA 1 -- Enigma Logic PA_SAM_TYPE_ENIGMA 1 -- Enigma Logic
PA_SAM_TYPE_DIGI_PATH 2 -- Digital Pathways PA_SAM_TYPE_DIGI_PATH 2 -- Digital Pathways
skipping to change at page 7, line 9 skipping to change at page 7, line 10
generate adequate keying material (sufficient length, secrecy, ran- generate adequate keying material (sufficient length, secrecy, ran-
domness) for the cryptographic algorithm used. If the single-use domness) for the cryptographic algorithm used. If the single-use
authentication data is not known (and cannot be generated or authentication data is not known (and cannot be generated or
discovered) by the KDC, then send-encrypted-sad flag will be set, discovered) by the KDC, then send-encrypted-sad flag will be set,
indicating that the SAD must be sent to the KDC encrypted under the indicating that the SAD must be sent to the KDC encrypted under the
principal's secret key. If neither use-sad-as-key nor send- principal's secret key. If neither use-sad-as-key nor send-
encrypted-sad are set, the client may assume that the KDC knows the encrypted-sad are set, the client may assume that the KDC knows the
SAD, but the Kerberos password should be used along with the SAD, but the Kerberos password should be used along with the
passcode in the derivation of the encryption key (see below). No passcode in the derivation of the encryption key (see below). No
more than one of the send-encrypted-sad and use-sad-as-key flags more than one of the send-encrypted-sad and use-sad-as-key flags
shoudl be in a SAM-CHALLENGE-2. should be in a SAM-CHALLENGE-2.
The must-pk-encrypt-sad flag is reserved for future use. If this The must-pk-encrypt-sad flag is reserved for future use. If this
flag is set and a client does not support the must-pk-encrypt-sad flag is set and a client does not support the must-pk-encrypt-sad
option (to be defined in a separate document), the client will not option (to be defined in a separate document), the client will not
be able to complete the authentication and must notify the user. be able to complete the authentication and must notify the user.
5.1.3 SAM-CHECKSUM Field 5.1.3 SAM-CHECKSUM Field
The sam-cksum field contains a sequence of at least one crypto- The sam-cksum field contains a sequence of at least one crypto-
graphic checksum of encoding of the PA-SAM-CHALLENGE-2 sequence. graphic checksum of encoding of the PA-SAM-CHALLENGE-2 sequence.
skipping to change at page 7, line 42 skipping to change at page 7, line 43
case, the KDC may elect to return multiple checksums, one for each case, the KDC may elect to return multiple checksums, one for each
possible SAD response. The number of possible responses of course possible SAD response. The number of possible responses of course
depends on the mechanism and site policy. In the case where multi- depends on the mechanism and site policy. In the case where multi-
ple checksums are returned, the client MUST try each checksum in ple checksums are returned, the client MUST try each checksum in
turn until one of the checksums is verified successfully. Note turn until one of the checksums is verified successfully. Note
that in the non-send-encrypted-sad case the checksum cannot be ver- that in the non-send-encrypted-sad case the checksum cannot be ver-
ified until the user enters in the SAD, but if no checksum can be ified until the user enters in the SAD, but if no checksum can be
verified, the client MUST not send a response but instead return an verified, the client MUST not send a response but instead return an
error to the user. error to the user.
The sam-cksum field is generated by encoding the entire SAM- The sam-cksum field is generated by calculating the specified
CHALLENGE-2 sequence with a zero-length sam-cksum sequence. The checksum over the DER-encoded SAM-CHALLENGE-2-BODY sequence.
checksums are calculated over this encoding, and the SAM-
CHALLENGE-2 sequence is reencoded with all of the checksums in
place. Checksum verification is done by reencoding the decoded
SAM-CHALLENGE-2 sequence with a zero-length sam-cksum and trying
checksums until a valid one is found.
If no checksum is included, or is of the wrong type, or none are If no checksum is included, or is of the wrong type, or none are
found which are correct, the client MUST abort the dialogue with found which are correct, the client MUST abort the dialogue with
the KDC and issue, respectively, KRB5_SAM_NO_CHECKSUM, the KDC and issue, respectively, KRB5_SAM_NO_CHECKSUM,
KRB5_SAM_BAD_CHECKSUM_TYPE, or KRB5_SAM_BAD_CHECKSUM error mes- KRB5_SAM_BAD_CHECKSUM_TYPE, or KRB5_SAM_BAD_CHECKSUM error mes-
sages. sages.
5.1.4 SAM-TRACK-ID Field 5.1.4 SAM-TRACK-ID Field
The optional sam-track-id field may be returned by the KDC in the The optional sam-track-id field may be returned by the KDC in the
KRB_ERROR message. If present, the client MUST copy this field KRB_ERROR message. If present, the client MUST copy this field
into the corresponding field of the SAM response sent in the subse- into the corresponding field of the SAM response sent in the subse-
quent KRB_AS_REQ message. This field may be used by the KDC to quent KRB_AS_REQ message. This field may be used by the KDC to
match challenges and responses. It might be a suitably encoded match challenges and responses. It might be a suitably encoded
integer, or even be encrypted data with the KDC state encoded so integer, or even be encrypted data with the KDC state encoded so
that the KDC doesn't have to maintain the state internally. Note that the KDC doesn't have to maintain the state internally. Note
that when a KDC supplies a sam-track-id, it MUST link the sam- that when a KDC supplies a sam-track-id, it MUST link the sam-
track-id with the sam-nonce field to prevent spoofing of the sam- track-id with the sam-nonce field to prevent spoofing of the sam-
track-id field. track-id field.
skipping to change at page 9, line 45 skipping to change at page 9, line 40
application-specific manner. application-specific manner.
Once the user has been prompted for and entered the SAD (and possi- Once the user has been prompted for and entered the SAD (and possi-
bly the Kerberos password), the client will derive a key to be used bly the Kerberos password), the client will derive a key to be used
to encrypt the preauthentication data for a KRB_AS_REQ message. to encrypt the preauthentication data for a KRB_AS_REQ message.
This key will be determined as follows: This key will be determined as follows:
By default, the key is derived from the password and the SAD By default, the key is derived from the password and the SAD
by running each through the string_to_key function [RFC1510] by running each through the string_to_key function [RFC1510]
separately; i.e., K1 = string_to_key(password) and K2 = separately; i.e., K1 = string_to_key(password) and K2 =
string_to_key(SAD). The K1 and K2 are then combined to form string_to_key(SAD). When the keys are both DES or 3DES,
a single key K using the algorithm described in Appendix A. keys K1 and K2 will be combined using the algorithm
described in Appendix B, ``DES/3DES Key Combination Algo-
rithm''. For all other encryption algorithms, the algorithm
described in Appendix A, ``Key Combination Algorithm'' shall
be used. Note that this algorithm is not commutative; an
implementation MUST insure that K1 is the key corresponding
to the user's long-term password, and K2 is the output from
the SAD. In either case, the salt used by the string_to_key
algorithm for the SAD shall be the same salt as used for the
user's password.
If the send-encrypted-sad flag is set, the key will be If the send-encrypted-sad flag is set, the key will be
derived by running the Kerberos password though the derived by running the Kerberos password though the
string_to_key function in the normal fashion. string_to_key function in the normal fashion.
If the use-sad-as-key flag is set and the integrity of the If the use-sad-as-key flag is set and the integrity of the
PA-SAM-CHALLENGE-2 PADATA field can be verified using the PA-SAM-CHALLENGE-2 PADATA field can be verified using the
sam-cksum field, then the SAD is run through the sam-cksum field, then the SAD is run through the
string_to_key function and the result is used as the encryp- string_to_key function and the result is used as the encryp-
tion key for the request. WARNING: the use of single-use tion key for the request. WARNING: the use of single-use
skipping to change at page 10, line 28 skipping to change at page 10, line 33
separate document), the client will not be able to complete separate document), the client will not be able to complete
the authentication and must notify the user. the authentication and must notify the user.
5.3 SAM-RESPONSE PA-DATA 5.3 SAM-RESPONSE PA-DATA
The client will then send another KRB_AS_REQ message to the KDC, The client will then send another KRB_AS_REQ message to the KDC,
but with a padata field with padata-type equal to PA-SAM-RESPONSE-2 but with a padata field with padata-type equal to PA-SAM-RESPONSE-2
and padata-value defined as follows: and padata-value defined as follows:
PA-SAM-RESPONSE-2 ::= SEQUENCE { PA-SAM-RESPONSE-2 ::= SEQUENCE {
sam-type[0] INTEGER, sam-type[0] INTEGER (0..4294967295),
sam-flags[1] SAMFlags, sam-flags[1] SAMFlags,
sam-track-id[2] GeneralString OPTIONAL, sam-track-id[2] GeneralString OPTIONAL,
sam-enc-nonce-or-sad[3] EncryptedData, sam-enc-nonce-or-sad[3] EncryptedData,
-- PA-ENC-SAM-RESPONSE-ENC -- PA-ENC-SAM-RESPONSE-ENC
sam-nonce[4] INTEGER, -- Key usage of 27
sam-nonce[4] INTEGER (0..4294967295),
... ...
} }
PA-ENC-SAM-RESPONSE-ENC ::= SEQUENCE { PA-ENC-SAM-RESPONSE-ENC ::= SEQUENCE {
sam-nonce[0] INTEGER, sam-nonce[0] INTEGER (0..4294967295),
sam-sad[1] GeneralString OPTIONAL, sam-sad[1] GeneralString OPTIONAL,
... ...
} }
The source of the data included in the PA-SAM-RESPONSE-2 structure The source of the data included in the PA-SAM-RESPONSE-2 structure
depends upon whether or not a KRB_ERROR message was received by the depends upon whether or not a KRB_ERROR message was received by the
client from the KDC. client from the KDC.
5.3.1 SAM-TYPE, SAM-FLAGS, and SAM-NONCE Fields 5.3.1 SAM-TYPE, SAM-FLAGS, and SAM-NONCE Fields
skipping to change at page 11, line 13 skipping to change at page 11, line 18
sam-type codes. sam-type codes.
The value of the sam-flags field may vary depending upon the type The value of the sam-flags field may vary depending upon the type
of SAM in use, but in all cases the must-pk-encrypt-sad flag must of SAM in use, but in all cases the must-pk-encrypt-sad flag must
be zero. If the send-encrypted-sad flag is set, the sam-sad field be zero. If the send-encrypted-sad flag is set, the sam-sad field
must contain the entered single-use authentication data (see Sec- must contain the entered single-use authentication data (see Sec-
tion 5.3.3). tion 5.3.3).
5.3.2 SAM-TRACK-ID Field 5.3.2 SAM-TRACK-ID Field
Note that is there is no sam-track-id in the request, it should be Note that if there is no sam-track-id in the request, it MUST be
omitted in the response. Otherwise, the sam-track-id data must be omitted in the response. Otherwise, the sam-track-id data MUST be
copied from the SAM-CHALLENGE-2 to the SAM-RESPONSE-2. copied from the SAM-CHALLENGE-2 to the SAM-RESPONSE-2.
5.3.3 SAM-ENC-NONCE-OR-SAD 5.3.3 SAM-ENC-NONCE-OR-SAD
The sam-enc-nonce-or-sad field represends the results of the preau- The sam-enc-nonce-or-sad field represends the results of the preau-
thentication process. It contains the encrypted SAD or a SAD- thentication process. It contains the encrypted SAD or a SAD-
encrypted nonce. The PA-ENC-SAM-RESPONSE-ENC message is encrypted encrypted nonce. The PA-ENC-SAM-RESPONSE-ENC message is encrypted
with the SAD, password + SAD, or password (based on the sam-flags) with the SAD, password + SAD, or password (based on the sam-flags)
with key usage 27. The fields of the PA-ENC-SAM-REPONSE-ENC mes- with key usage 27. The fields of the PA-ENC-SAM-REPONSE-ENC mes-
sage are populated as follows: sage are populated as follows:
skipping to change at page 12, line 4 skipping to change at page 12, line 9
however, that some single-use authentication mechanisms may require however, that some single-use authentication mechanisms may require
further KRB_AS_REQ/KRB_ERROR exchanges to complete authentication; further KRB_AS_REQ/KRB_ERROR exchanges to complete authentication;
for example, in order to allow the server to resynchronize with the for example, in order to allow the server to resynchronize with the
drifting clock on a time-based token card. In these cases the KDC drifting clock on a time-based token card. In these cases the KDC
may respond with another KRB_ERROR message containing a different may respond with another KRB_ERROR message containing a different
sam-type value, along with appropriate prompts and/or challenges. sam-type value, along with appropriate prompts and/or challenges.
This sequence of exchanges will continue until authentication This sequence of exchanges will continue until authentication
either succeeds or fails. either succeeds or fails.
6. Requirements for Single-use Authentication Mechanisms 6. Requirements for Single-use Authentication Mechanisms
Single-Use Authentication Mechanisms vary in their capabilities. Single-Use Authentication Mechanisms vary in their capabilities.
To aid implementers, we summarize here how various types of SAMs To aid implementers, we summarize here how various types of SAMs
would operate using this protocool. would operate using this protocool.
If a SAM system can provide a SAD or a sequence of valid SADs to If a SAM system can provide a SAD or a sequence of valid SADs to
the KDC, then the implementation should NOT set the send- the KDC, then the implementation SHOULD NOT set the send-
encrypted-sad flag. This SAM system should provide the SAD to the encrypted-sad flag. This SAM system should provide the SAD to the
KDC, which will combine it with the user's long-term key (password) KDC, which will combine it with the user's long-term key (password)
to generate the key used to generate the checksum placed in the to generate the key used to generate the checksum placed in the
sam-cksum field in the PA-SAM-CHALLENGE-2 message. This combined sam-cksum field in the PA-SAM-CHALLENGE-2 message. This combined
key will also be used by the KDC to verify PA-SAM-RESPONSE-2 mes- key will also be used by the KDC to verify PA-SAM-RESPONSE-2 mes-
sage by using it to decrypt the sam-enc-nonce-or-sad field and as sage by using it to decrypt the sam-enc-nonce-or-sad field and as
the key to encrypt the KRB-AS-REP. If a SAM system returns a range the key to encrypt the KRB-AS-REP. If a SAM system returns a range
of valid responses, each response can be used to generate a valid of valid responses, each response can be used to generate a valid
checksum which can be placed in the sam-cksum sequence. checksum which can be placed in the sam-cksum sequence.
skipping to change at page 12, line 57 skipping to change at page 13, line 9
decrypt the response and obtain the single-use authentication data. decrypt the response and obtain the single-use authentication data.
This is dependent on the SAM technology used. This is dependent on the SAM technology used.
If the KDC sets the must-pk-encrypt-sad flag of the sam-flags field If the KDC sets the must-pk-encrypt-sad flag of the sam-flags field
but the client software being used does not support public-key but the client software being used does not support public-key
cryptography, it is possible that legitimate users may be denied cryptography, it is possible that legitimate users may be denied
service. service.
An attacker in possession of the users encryption key (again, which An attacker in possession of the users encryption key (again, which
doesn't change from login to login) might be able to doesn't change from login to login) might be able to
generate/modify a SAM challenge and attach the appropriate generate/modify a SAM challenge and attach the appropriate check-
checksum. This affects the security of both the send-encrypted-sad sum. This affects the security of both the send-encrypted-sad
option and the must-pk-encrypt-sad option. option and the must-pk-encrypt-sad option.
8. Expiration 8. Expiration
This Internet-Draft expires on April 2, 2003. This Internet-Draft expires on April 27, 2004.
9. References 9. References
[RFC1510] [RFC1510]
The Kerberos Network Authentication System; Kohl and Neuman; The Kerberos Network Authentication System; Kohl and Neuman;
September 1993. September 1993.
[RFC1760] [RFC1760]
The S/Key One-Time Password System; Haller; February 1995 The S/Key One-Time Password System; Haller; February 1995
[RFC1636] [RFC1636]
Report of IAB Workshop on Security in the Internet Architec- Report of IAB Workshop on Security in the Internet Architec-
ture; Braden, Clark, Crocker and Huitema; June 1994 ture; Braden, Clark, Crocker and Huitema; June 1994
[KCRYPTO] [KCRYPTO]
Encryption and Checksum Specifications for Kerberos 5; Rae- Encryption and Checksum Specifications for Kerberos 5; Rae-
burn; May 2002 burn; May 2002
10. Authors' Addresses 10. Authors' Addresses
Ken Hornstein
Naval Research Laboratory
4555 Overlook Avenue
Washington, DC 20375
Phone: 202-404-4765
EMail: kenh@cmf.nrl.navy.mil
Ken Renard
WareOnEarth
6849 Old Dominion Dr, Suite 365
Annandale, VA 22003
Phone: 703-622-3469
EMail: kdrenard@wareonearth.com
B. Clifford Neuman B. Clifford Neuman
USC/Information Sciences Institute USC/Information Sciences Institute
4676 Admiralty Way #1001 4676 Admiralty Way #1001
Marina del Rey, CA 90292-6695 Marina del Rey, CA 90292-6695
Phone: 310-822-1511 Phone: 310-822-1511
EMail: bcn@isi.edu EMail: bcn@isi.edu
Glen Zorn Glen Zorn
Cisco Systems Cisco Systems
500 108th Ave NE 500 108th Ave NE
Suite 500 Suite 500
Bellevue, WA 98004 Bellevue, WA 98004
Phone: 425-344-8113 Phone: 425-344-8113
EMail: gwz@cisco.com EMail: gwz@cisco.com
Ken Hornstein Appendix A - Key combination algorithm
Naval Research Laboratory
4555 Overlook Avenue
Washington, DC 20375
Phone: 202-404-4765 Definitions:
EMail: kenh@cmf.nrl.navy.mil
Ken Renard prf - Pseudo-random function that outputs an octet string based on
WareOnEarth an input key and a input octet string (defined in [KCRYPTO])
6849 Old Dominion Dr, Suite 365
Annandale, VA 22003
Phone: 703-622-3469 ^ - Exclusive-OR operation
EMail: kdrenard@wareonearth.com
Appendix A - Key combination algorithm random-to-key - Generates an encryption key from random input
(defined in [KCRYPTO])
Given two input keys, K1 and K2, where K1 is derived from the
user's long-term password, and K2 is derived from the SAD, output
key (K3) is derived as follows:
Two sequence of octets, R1 and R2, shall be produced for each key
K1 and K2. R1 and R2 will be generated by iterating over calls to
prf() until enough bits are generated as needed by the random-to-
key function for the encryption type specified for K3.
The octet-string parameter to the prf() function shall be the ASCII
string "CombineA" for K1, and "CombineB" for K2. These have the
following byte values:
{ 0x43 0x6f 0x6d 0x62 0x69 0x6e 0x65 0x41 }
{ 0x43 0x6f 0x6d 0x62 0x69 0x6e 0x65 0x42 }
Furthermore, on each iteration both octet-strings will have
appended to them the iteration count in the form of an ASCII, base
10, numeral. The iteration count shall start at zero. The format
of the iteration count is equivalant to the C language "%d" format
to the printf() function call. Pseudo code implementing this fol-
lows:
count = 0;
while ( bits < required_bits) {
sprintf(A1, "CombineA%d", count);
sprintf(A2, "CombineB%d", count);
R1 += prf(K1, A1);
R2 += prf(K2, A2);
count++;
}
When R1 and R2 have been generated, they are truncated if the they
are longer than the length required by random-to-key. The key is
then generated as follows:
K3 = random-to-key(R1 ^ R2)
Appendix B - DES/3DES Key combination algorithm
Definitions: Definitions:
DR - generate "random" data from an encryption key (defined in DR - generate "random" data from an encryption key (defined in
[KCRYPTO]) [KCRYPTO])
n-fold - "stretches" or "shrinks" a sequence bits to a specified n-fold - "stretches" or "shrinks" a sequence bits to a specified
size (defined in [KCRYPTO]) size (defined in [KCRYPTO])
random-to-key - Generates an encryption key from random input random-to-key - Generates an encryption key from random input
(defined in [KCRYPTO]) (defined in [KCRYPTO])
DK - Derive-Key, defined in [KCRYPTO]) DK - Derive-Key, defined in [KCRYPTO])
CombineConstant - The ASCII encoding of the string "combine", which CombineConstant - The ASCII encoding of the string "combine",
is defined as the following byte string: which is defined as the following byte string:
{ 0x63 0x6f 0x6d 0x62 0x69 0x6e 0x65 } { 0x63 0x6f 0x6d 0x62 0x69 0x6e 0x65 }
Note: | means "concatenate" Note: | means "concatenate"
Given two input keys, K1 and K2, the Combine-Key function is as Given two input keys, K1 and K2, the Combine-Key function is as
follows: follows:
R1 = DR(K1, n-fold(K2)) R2 = DR(K2, n-fold(K1)) R1 = DR(K1, n-fold(K2)) R2 = DR(K2, n-fold(K1))
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/