get the prototype right for yyparse, it returns an int

[heimdal.git] / doc / standardisation / draft-ietf-krb-wg-kerberos-sam-02.txt

INTERNET-DRAFT                                           Ken Hornstein
<draft-ietf-krb-wg-kerberos-sam-02.txt>      Naval Research Laboratory
Updates: RFC 1510                                           Ken Renard
October 27, 2003                                           WareOnEarth
                                                       Clifford Newman
                                                                   ISI
                                                             Glen Zorn
                                                         Cisco Systems



      Integrating Single-use Authentication Mechanisms with Kerberos


0. Status Of this Memo
   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.  Internet-Drafts are working documents of
   the Internet Engineering Task Force  (IETF),  its  areas,  and  its
   working groups.  Note that other groups may also distribute working
   documents as Internet-Drafts.

   Internet-Drafts are draft documents valid  for  a  maximum  of  six
   months  and  may  be updated, replaced, or obsoleted by other docu-
   ments at any time.  It is inappropriate to use  Internet-Drafts  as
   reference  material  or  to  cite them other than as ``work in pro-
   gress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Sha-
   dow Directories on ds.internic.net (US East  Coast),  nic.nordu.net
   (Europe),  ftp.isi.edu  (US  West Coast), or munnari.oz.au (Pacific
   Rim).

   The distribution of  this  memo  is  unlimited.   It  is  filed  as
   <draft-ietf-krb-wg-kerberos-sam-02.txt>,   and  expires  April  27,
   2004.  Please send comments to the authors.


1. Abstract
   This document defines extensions to the Kerberos protocol  specifi-
   cation  [RFC1510]  which  provide  a  method  by which a variety of
   single-use authentication mechanisms may be  supported  within  the
   protocol.  The method defined specifies a standard fashion in which
   the preauthentication data and error data fields in  Kerberos  mes-
   sages may be used to support single-use authentication mechanisms.


2. Terminology
   To simplify the following discussion, we will  define  those  terms
   which  may be unfamiliar to the audience or specific to the discus-
   sion itself.

   Single-use Preauthentication Data (SPD):  Data sent in the  padata-
   value  field  of  a  Kerberos  V5 message proving that knowledge of



Hornstein, Renard, Newman, Zorn                               [Page 1]





INTERNET-DRAFT                                        October 27, 2003


   certain unique information is held by a principal.   This  informa-
   tion  may  or may not be identical to the single-use authentication
   data input to the client.  For example, in the case of  S/Key,  the
   principal  might  input  a  one-time  password  (in  any of several
   forms); the knowledge of this one-time password is taken  to  indi-
   cate  knowledge  of  the principal's secret passphrase.  Similarly,
   the SPD may or may not contain the provided single-use  authentica-
   tion  data.   For  instance,  if  a given single-use authentication
   mechanism includes a token which generates an encryption key for  a
   supported  cryptosystem, that key could be used to encrypt portions
   of the SPD before transmission.  As long as the  verification  pro-
   cess  of  the mechanism was capable of independently generating the
   same key, the  successful  decryption  of  the  SPD  would  provide
   assurance  that  the originator of the message was in possession of
   the token, as well as whatever information the  token  required  to
   generate the encryption key.

   Single-use Authentication Mechanism (SAM):  A system for generating
   and verifying authentication data which is usable only once.

   Single-use Authentication Data (SAD):  SAM-specific  data  provided
   by  a principal as input to client software to be used in the crea-
   tion of SPD.


3. Motivation and Scope
   Several  single-use  authentication  mechanisms  are  currently  in
   widespread  use, including hardware-based schemes from vendors such
   as Enigma Logic, CRYPTOCard, and Security  Dynamics  and  software-
   based  methods  like  S/Key  [RFC1760].  The hardware-based schemes
   typically require that  the  authenticating  user  carry  a  small,
   credit-card-sized  electronic device (called a token) which is used
   to generate unique authentication data.  Some  tokens  require  the
   user  to  enter data into the device.  This input may take the form
   of a Personal Identification Number (PIN), a server-generated chal-
   lenge string or both.  Other tokens do not use a challenge-response
   technique, instead spontaneously generating new and unique  authen-
   tication  data  every  few seconds.  These tokens are usually time-
   synchronized with a server.  The  use  of  one-time  passwords  and
   token  cards  as an authentication mechanism has steadily increased
   over the past few years; in  addition,  the  Internet  Architecture
   Board  has  encouraged the use of SAMs to improve Internet security
   [RFC1636].

   The widespread acceptance of Kerberos within the Internet community
   has  produced  considerable demand for the integration of SAM tech-
   nology with the authentication protocol.  Several currently  avail-
   able  implementations of Kerberos include support for some types of
   token cards, but the implementations are either not  interoperable,
   or  would require the release of source code (not always an option)
   to make them interoperate.  This memo attempts to remedy that prob-
   lem  by specifying a method in which SAM data may be securely tran-
   sported in Kerberos V5 messages in a standard, extensible  fashion.
   This  document  does  not,  however,  attempt  to precisely specify



Hornstein, Renard, Newman, Zorn                               [Page 2]





INTERNET-DRAFT                                        October 27, 2003


   either the generation or verification of SAM data,  since  this  is
   likely to be SAM-specific; nor does it dictate the conditions under
   which SAM data must be included in Kerberos messages, since we con-
   sider this to be a matter of local policy.

   A primary reason for using a SAM with Kerberos  is  to  reduce  the
   threat  from  common  attacks  on Kerberos passwords (poorly chosen
   passwords, password guessing, etc).  If passwords are used in  com-
   bination  with  SAM authentication data, users must still adhere to
   sensible password policies and safe practices regarding the  selec-
   tion,  secrecy,  and  maintenance of their passwords.  Depending on
   the specific mechanism used, the purpose of the SAD is  to  augment
   (or sometimes replace) the use of a password as a secret key.


4. Generic Approach - Two Models
   As outlined above, there are essentially two  types  of  single-use
   authentication  mechanisms:  challenge/response and time-based.  In
   order to support challenge/response mechanisms,  the  Kerberos  Key
   Distribution  Center  (KDC)  must communicate the appropriate chal-
   lenge string to the user, via the  client  software.   Furthermore,
   some  challenge/response  mechanisms  require tight synchronization
   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
   same number of message digest iterations, the protocol  will  fail;
   worse,  it  might be possible for an eavesdropping attacker to cap-
   ture a valid S/Key passcode and replay it to a  KDC  replica  which
   had an outdated iteration number.  In the time-based case, no chal-
   lenge is required.  This naturally  gives  rise  to  two  modes  of
   client behavior, described below.


4.1 Challenge/Response Model
   The client begins with an initial KRB_AS_REQ message  to  the  KDC,
   possibly using existing preauthentication methods (PA-ENC-TIMESTAMP
   (encrypted  timestamp),  PA-OSF-DCE  (DCE),  etc.).   Depending  on
   whether  preauthentication  is  used,  the  user  may or may not be
   prompted at this time for a Kerberos password.   If  (for  example)
   encrypted  timestamp  preauthentication is used, then the user will
   be prompted; on the other hand, if no preauthentication is  in  use
   the  prompt  for  the  password may be deferred (possibly forever).
   Note that the use of preauthentication here may  allow  an  offline
   guessing  attack  against  the  Kerberos password separate from the
   SPD.  However, if the use of a SAM is required, then  the  password
   by itself is not sufficient for authentication.  (Specify character
   strings as UTF-8)

   The KDC will determine in an implementation-  and  policy-dependent
   fashion if the client is required to utilize a single-use authenti-
   cation mechanism.  For  example,  the  implementation  may  use  IP
   address screening to require principals authenticating from outside
   a firewall to use a SAM, while principals on the inside  need  not.
   If  SAM  usage  is  required,  then  the  KDC  will  respond with a
   KRB_ERROR   message,   with   the   error-code   field    set    to



Hornstein, Renard, Newman, Zorn                               [Page 3]





INTERNET-DRAFT                                        October 27, 2003


   KDC_ERR_PREAUTH_REQUIRED  and the e-data field containing the ASN.1
   structure that is a sequence of PA-DATA fields.

   If the type of one of the PA-DATA fields  is  PA-SAM-REDIRECT,  the
   client  should  re-execute  the  authentication  protocol  from the
   beginning, directing messages to another of the KDCs for the realm.
   This  is done to allow some methods to require that a single KDC be
   used for SAM authentication when tight  synchronization  is  needed
   between all replicas and the KDC database propagation code does not
   provide such synchronization.  The corresponding padata-value  will
   contain an encoded sequence of host addresses [RFC1510], from which
   the client must choose the KDC to be contacted next.   The  PA-SAM-
   REDIRECT is defined as:


   PA-SAM-REDIRECT ::=    HostAddresses


   Client implementations SHOULD check the addresses  in  the  PA-SAM-
   REDIRECT  and  verify  that  they are a subset of the KDC addresses
   that they have been configured for that realm.

   If none of the PA-DATA fields have a value of PA-SAM-REDIRECT, then
   if  one  of the PA-DATA fields has the type PA-SAM-CHALLENGE-2, the
   exchange will continue as described in section 5, below.

   Note that some Kerberos implementations support an older preauthen-
   tication  mechanism  with the padata types PA-SAM-CHALLENGE and PA-
   SAM-RESPONSE.  That protocol is depreciated and not defined here.


4.2 Time-based Model
   For mechanisms where no challenge is required,  the  user  (or  the
   client  software  being  utilized)  may  or  may  not know a priori
   whether SAM usage is required.  If it does not know, then the  ini-
   tial exchange may proceed as above.  If it is known that a use of a
   single-use authentication mechanism  is  required  then  the  first
   exchange  can  be  skipped  and the authentication will continue as
   follows.


5. SAM Preauthentication

   An optional SAM-CHALLENGE-2 may be sent from the KDC to the  client
   and  the  client  will  send a SAM-RESPONSE-2 as pre-authentication
   data in the KRB-AS-REQ.  The details of the messages follow.

5.1 SAM-CHALLENGE-2

   Prior to performing preauthentication using a single-use  authenti-
   cation  mechanism,  the  client  must  know  whether a challenge is
   required (if the client doesn't have this information prior to  its
   sending  the  first  KRB_AS_REQ message, it will be informed of the
   requirement by the KDC, as described in section  4.1).  The  client



Hornstein, Renard, Newman, Zorn                               [Page 4]





INTERNET-DRAFT                                        October 27, 2003


   does  NOT need to know the specific type of SAM in use.  If a chal-
   lenge is required the client will be sent the challenge by the KDC.
   This  means that a client supporting SAMs will be able to work with
   new methods without modification.  The challenge, as  well  as  all
   other prompts mentioned herein, can be internationalized by the KDC
   on a per-principal basis.

   If a KRB_ERROR message is received from the KDC indicating that SAM
   usage  is required, that message will include in its e-data field a
   PA-DATA structure that encodes information  about  the  SAM  to  be
   used.   This  includes  whether a challenge is required, and if so,
   the challenge itself; and informational data about the type of  SAM
   that  is  in  use,  and how to prompt for the SAD.  The SAM type is
   informational only and does not affect the behavior of the  client.
   The  prompt  is also informational and may be presented to the user
   by the client, or it may be safely ignored.

   The ASN.1 definition for the SAM challenge is:

          PA-SAM-CHALLENGE-2 ::= SEQUENCE {
              sam-body[0]                 PA-SAM-CHALLENGE-2-BODY,
              sam-cksum[1]                SEQUENCE (1..MAX) OF Checksum,
              ...
          }

          PA-SAM-CHALLENGE-2-BODY ::= SEQUENCE {
              sam-type[0]                 INTEGER (0..4294967295),
              sam-flags[1]                SAMFlags,
              sam-type-name[2]            GeneralString OPTIONAL,
              sam-track-id[3]             GeneralString OPTIONAL,
                                            -- Key usage of 26
              sam-challenge-label[4]      GeneralString OPTIONAL,
              sam-challenge[5]            GeneralString OPTIONAL,
              sam-response-prompt[6]      GeneralString OPTIONAL,
              sam-pk-for-sad[7]           OCTET STRING OPTIONAL,
              sam-nonce[8]                INTEGER (0..4294967295),
              sam-etype[9]                INTEGER (0..4294967295),
              ...
          }

          SAMFlags ::= BIT STRING (SIZE (32..MAX))
              -- use-sad-as-key(0)
              -- send-encrypted-sad(1)
              -- must-pk-encrypt-sad(2)

5.1.1  SAM-TYPE and SAM-TYPE-NAME Fields

   The sam-type field is informational only, but it must be  specified
   and sam-type values must be registered with the IANA.

   Initially defined values of the sam-type codes are:

       PA_SAM_TYPE_ENIGMA     1   -- Enigma Logic
       PA_SAM_TYPE_DIGI_PATH  2   -- Digital Pathways



Hornstein, Renard, Newman, Zorn                               [Page 5]





INTERNET-DRAFT                                        October 27, 2003


       PA_SAM_TYPE_SKEY_K0    3   -- S/key where  KDC has key 0
       PA_SAM_TYPE_SKEY       4   -- Traditional S/Key
       PA_SAM_TYPE_SECURID    5   -- Security Dynamics
       PA_SAM_TYPE_CRYPTOCARD 6   -- CRYPTOCard

   PA_SAM_TYPE_SECURID, PA_SAM_TYPE_DIGI_PATH, PA_SAM_TYPE_ENIGMA, and
   PA_SAM_TYPE_CRYPTOCARD     represent     popular    token    cards.
   PA_SAM_TYPE_SKEY is the traditional S/Key protocol,  in  which  the
   SAD  verifier  does  not  have  knowledge  of the principal's S/Key
   secret.  PA_SAM_TYPE_SKEY_K0 is a variant of S/Key  that  uses  the
   same  SAD  and PC software or hardware device, but where the zeroth
   key (the S/Key secret) is actually stored on, and can be  used  by,
   the  SAD verifier to independently generate the correct authentica-
   tion data.

   Note that using  PA_SAM_TYPE_SKEY_K0  gives  up  one  advantage  of
   S/Key, viz., that the information required to generate the SAD need
   not be stored on the host; but since the SAD verifier (which may be
   the  KDC) is assumed to be more secure than other hosts on the net-
   work, it may be acceptable to give up this advantage in some situa-
   tions.  The advantage of using this S/Key variant is that the secu-
   rity of the network protocol is strengthened since the SAD need not
   be  sent  from the client to the KDC.  Thus, the SAD can be used as
   part of the key used to encrypt the encrypted parts of both the SPD
   and the KRB_AS_REP message, rather than being sent protected by the
   principal's Kerberos secret key  which  may  have  been  previously
   exposed  to an attacker (see section 6, below).  In any case, there
   is a definite advantage to being interoperable with the S/Key algo-
   rithm.

   Due to the volatility of, and rapid developments in,  the  area  of
   single-use   authentication   mechanisms  (both  software-only  and
   hardware supported), any subsequently defined sam-type  codes  will
   be maintained by the IANA.

   The optional sam-type-name field is a UTF-8  character  string  for
   informational  use only.  It may be used by the client to display a
   short description of the type of single-use authentication  mechan-
   ism to be used.

5.1.2  SAM-FLAGS Field

   The sam-flags field indicates whether the SAD is known by  the  KDC
   (in which case it can be used as part of the encryption key for the
   ensuing KRB_AS_REP message), or if it must be provided to  the  KDC
   in a recoverable manner.  If it is known to the KDC, use-sad-as-key
   indicates that the SAD alone will be used to generate  the  encryp-
   tion  key  for  the forthcoming KRB_AS_REQ and KRB_AS_REP messages,
   and that the user will not need  to  also  enter  a  password.   We
   recommend  that this option only be used if the SAD will be used to
   generate adequate keying material (sufficient length, secrecy, ran-
   domness)  for  the cryptographic algorithm used.  If the single-use
   authentication data is  not  known  (and  cannot  be  generated  or
   discovered)  by  the KDC, then send-encrypted-sad flag will be set,



Hornstein, Renard, Newman, Zorn                               [Page 6]





INTERNET-DRAFT                                        October 27, 2003


   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-
   encrypted-sad are set, the client may assume that the KDC knows the
   SAD,  but  the  Kerberos  password  should  be  used along with the
   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
   should be in a SAM-CHALLENGE-2.

   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
   option (to be defined in a separate document), the client will  not
   be able to complete the authentication and must notify the user.

5.1.3  SAM-CHECKSUM Field

   The sam-cksum field contains a sequence of  at  least  one  crypto-
   graphic  checksum  of  encoding of the PA-SAM-CHALLENGE-2 sequence.
   If the send-encrypted-sad flag is set, the key to be used for  this
   checksum  is  the client's long-term secret.  If the use-sad-as-key
   flag is set, then the SAD alone will be used as the key.   If  nei-
   ther  flag  is  set, then the key used for this checksum is derived
   from the SAD and the user's password (see section 5.2).

   The checksum algorithm to be used for this is the mandatory  check-
   sum  associated with the encryption algorithm specified in the sam-
   etype field, with a key usage of 25.

   In some cases there may be more than one valid SAD; some preauthen-
   tication  mechanisms  may have a range of valid responses.  In that
   case, the KDC may elect to return multiple checksums, one for  each
   possible  SAD response.  The number of possible responses of course
   depends on the mechanism and site policy.  In the case where multi-
   ple  checksums  are  returned, the client MUST try each checksum in
   turn until one of the checksums  is  verified  successfully.   Note
   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
   verified, the client MUST not send a response but instead return an
   error to the user.

   The sam-cksum field  is  generated  by  calculating  the  specified
   checksum over the DER-encoded SAM-CHALLENGE-2-BODY sequence.

   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
   the   KDC   and    issue,    respectively,    KRB5_SAM_NO_CHECKSUM,
   KRB5_SAM_BAD_CHECKSUM_TYPE,  or  KRB5_SAM_BAD_CHECKSUM  error  mes-
   sages.

5.1.4  SAM-TRACK-ID Field

   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
   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



Hornstein, Renard, Newman, Zorn                               [Page 7]





INTERNET-DRAFT                                        October 27, 2003


   match challenges and responses.  It might  be  a  suitably  encoded
   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  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 field.

   The key usage type 26 is reserved  for  use  to  encrypt  the  sam-
   track-id  data.   The  key  used  to  encrypt  the  sam-track-id is
   mechanism-dependent.

5.1.5  SAM-CHALLENGE-LABEL Field

   The sam-challenge-label field is informational and optional.  If it
   is  included, is will be an UTF-8 encoded character.  If present, a
   client may choose to precede the presentation of the challenge with
   this  string.   For  example,  if  the  challenge is 135773 and the
   string in the sam-challenge-label field  is  "Enter  the  following
   number on your card", the client may choose to display to the user:

          Enter the following number on your card: 135773

   If no challenge label was presented, or if the  client  chooses  to
   ignore it, the client might display instead:

          Challenge from authentication server: 135773

   Internationalization is supported by allowing customization of  the
   challenge  label  and other strings on a per-principal basis.  Note
   that this character string should be encoded using UTF-8.

5.1.6  SAM-CHALLENGE Field

   The optional sam-challenge field contains a  string  that  will  be
   needed  by  the  user to generate a suitable response.  If the sam-
   challenge field is left out, it indicates that the SAM in use  does
   not  require  a  challenge,  and that the authorized user should be
   able to produce the correct SAD without one.  If the  sam-challenge
   field  is present, it is the data that is used by the SAD generator
   to create the SAD to be used in the production of  the  SPD  to  be
   included in the response.

5.1.7  SAM-RESPONSE-PROMPT Field

   The sam-response-prompt field is informational  and  optional.   If
   present, a client may choose to precede the prompt for the response
   with the specified string.

          Passcode:

5.1.8  SAM-PK-FOR-SAD Field

   sam-pk-for-sad is  an  optional  field.   It  is  included  in  the
   interest  of  future  extensability  of  the protocol to the use of



Hornstein, Renard, Newman, Zorn                               [Page 8]





INTERNET-DRAFT                                        October 27, 2003


   public-key cryptography.

5.1.9  SAM-NONCE Field

   The sam-nonce is a KDC-supplied nonce and  should  conform  to  the
   specification   of   the  nonce  field  in  a  KRB_KDC_REQ  message
   [RFC1510].

   Challenge/Response mechanisms MUST link the nonce  field  with  the
   sam-track-id  (if  one  is  included) to prevent replay of the sam-
   track-id field.

5.1.10  SAM-ETYPE Field

   The sam-etype field contains the encryption type to be used by  the
   client  for  all encrypted fields in the PA-SAM-RESPONSE-2 message.
   The KDC should pick an appropriate encryption  algorithm  based  on
   the   encryption   algorithms   listed   in  the  client's  initial
   KRB_AS_REQ.

5.2  Obtaining SAM Authentication Data

   If the client is performing SAM preauthentication  in  the  initial
   message,  without  receipt  of  a  PA-SAM-CHALLENGE-2 (i.e. without
   waiting for the KRB_ERROR message), and the SAM  in  use  does  not
   require  a  challenge,  the  client  will  prompt for the SAD in an
   application-specific manner.

   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
   to encrypt the preauthentication data  for  a  KRB_AS_REQ  message.
   This key will be determined as follows:

          By default, the key is derived from the password and the SAD
          by running each through the string_to_key function [RFC1510]
          separately; i.e., K1  =  string_to_key(password)  and  K2  =
          string_to_key(SAD).   When  the  keys  are both DES or 3DES,
          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
          derived   by   running  the  Kerberos  password  though  the
          string_to_key function in the normal fashion.

          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



Hornstein, Renard, Newman, Zorn                               [Page 9]





INTERNET-DRAFT                                        October 27, 2003


          sam-cksum  field,  then  the  SAD   is   run   through   the
          string_to_key function and the result is used as the encryp-
          tion key for the request.  WARNING: the  use  of  single-use
          authentication data in this manner is NOT recommended unless
          the range of the SAD is large enough to make  an  exhaustive
          off-line  search  impractical  and the risks involved in the
          use of SAD alone are  fully  considered.   Also,  note  that
          without  the availability to the KDC of a relatively static,
          unique secret key shared with the user, the only  mechanisms
          that  can  be  used  to protect the integrity of the PA-SAM-
          CHALLENGE-2 PADATA field are  based  on  either  public  key
          cryptography  or  the  KDC's  a  priori knowledge of the SAD
          itself.  In the latter case, the client must obtain the  SAD
          from  the  user  and  use  it to verify the integrity of the
          challenge before the new KRB_AS_REQ message is sent.

          The sam-pk-for-sad field is reserved  for  future  use.   If
          this  field is not empty and the client does not support the
          use of public-key encryption for SAD (to  be  defined  in  a
          separate  document), the client will not be able to complete
          the authentication and must notify the user.

5.3  SAM-RESPONSE PA-DATA

   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
   and padata-value defined as follows:

          PA-SAM-RESPONSE-2 ::= SEQUENCE {
              sam-type[0]                 INTEGER (0..4294967295),
              sam-flags[1]                SAMFlags,
              sam-track-id[2]             GeneralString OPTIONAL,
              sam-enc-nonce-or-sad[3]     EncryptedData,
                                             -- PA-ENC-SAM-RESPONSE-ENC
                                             -- Key usage of 27
              sam-nonce[4]                INTEGER (0..4294967295),
              ...
          }

          PA-ENC-SAM-RESPONSE-ENC ::= SEQUENCE {
               sam-nonce[0]               INTEGER (0..4294967295),
               sam-sad[1]                 GeneralString OPTIONAL,
               ...
          }

   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
   client from the KDC.

5.3.1  SAM-TYPE, SAM-FLAGS, and SAM-NONCE Fields

   If an error reply was received, the sam-type, sam-flags,  and  sam-
   nonce  fields will contain copies of the same fields from the error
   message.



Hornstein, Renard, Newman, Zorn                              [Page 10]





INTERNET-DRAFT                                        October 27, 2003


   If no error reply was received  (i.e.,  the  client  knows  that  a
   single-use  authentication  mechanism  is to be used), the sam-type
   field must be set to a value chosen from  the  list  of  registered
   sam-type codes.

   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
   be zero.  If the send-encrypted-sad flag is set, the sam-sad  field
   must  contain  the entered single-use authentication data (see Sec-
   tion 5.3.3).

5.3.2  SAM-TRACK-ID Field

   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
   copied from the SAM-CHALLENGE-2 to the SAM-RESPONSE-2.

5.3.3  SAM-ENC-NONCE-OR-SAD

   The sam-enc-nonce-or-sad field represends the results of the preau-
   thentication  process.   It  contains  the  encrypted SAD or a SAD-
   encrypted nonce.  The PA-ENC-SAM-RESPONSE-ENC message is  encrypted
   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-
   sage are populated as follows:

   The sam-nonce contains the nonce from the SAM-CHALLENGE-2.  This is
   the same as the unencrypted sam-nonce described in section 5.2.2.

   The sam-sad field contains the SAD if send-encrypted-sad is set  in
   the sam-flags.  Otherwise, it is omitted.

5.4  Verification of the SAM-RESPONSE-2

   Upon receipt the KDC validates this PADATA in  much  the  same  way
   that  it  validates  the  PA-ENC-TS preauthentication method except
   that it uses the SAD (if available,  and  possibly  in  conjunction
   with  saved  state information or portions of the preauthentication
   data) to determine  the  correct  key(s)  required  to  verify  the
   encrypted  data.   Note that if the KDC uses the sam-track-id field
   to encode its state, the SAM-verification routine   is  responsible
   for  including  information in that field to detect modification or
   replay by an attacker.

5.5  KRB5-AS-REP

   The rest of the processing of the request proceeds normally, except
   that  instead  of  being  encrypted  in  the user's secret key, the
   KRB_AS_REP message is encrypted in the key obtained  above.   Note,
   however, that some single-use authentication mechanisms may require
   further KRB_AS_REQ/KRB_ERROR exchanges to complete  authentication;
   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
   may  respond  with another KRB_ERROR message containing a different



Hornstein, Renard, Newman, Zorn                              [Page 11]





INTERNET-DRAFT                                        October 27, 2003


   sam-type value, along with appropriate prompts  and/or  challenges.
   This  sequence  of  exchanges  will  continue  until authentication
   either succeeds or fails.

6.  Requirements for Single-use Authentication Mechanisms

   Single-Use Authentication Mechanisms vary  in  their  capabilities.
   To  aid  implementers,  we summarize here how various types of SAMs
   would operate using this protocool.

   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-
   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)
   to generate the key used to generate the  checksum  placed  in  the
   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-
   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
   of  valid  responses, each response can be used to generate a valid
   checksum which can be placed in the sam-cksum sequence.

   If a SAM system can generate enough entropy, it can  set  the  use-
   sad-as-key  field  to use the SAD solely as keying material, but it
   should be noted that most SAM systems  that  require  the  user  to
   enter  in  a  response  do  not  have enough entropy to replace the
   user's long-term key.  The most likely consumer  of  use-sad-as-key
   is a hardware token which communicates a key directly with Kerberos
   client software.  With or without the use of  use-sad-as-key,  this
   is  the  preferred method as it protects against offline dictionary
   attacks against the user's password.

   If a SAM system cannot provide a SAD or a sequence of SADs  to  the
   KDC,  then  the send-encrypted-sad flag must be set.  In this case,
   the SAD will be encrypted using the user's  long-term  key  in  the
   PA-SAM-RESPONSE-2  message.   It  should  be  noted  that this is a
   weaker solution, as it does not protect the user's password against
   offline  dictionary attacks, and any additional entropy provided by
   the SAM system cannot be used.

7. Security considerations

   Single-use authentication  mechanisms  requiring  the  use  of  the
   send-encrypted-sad  option are discouraged as their use on the net-
   work is less secure than the case where a combination of the  users
   password  and  SAD  is  used as the encryption key.  In particular,
   when  the  send-encrypted-sad  option  is  used,  an  attacker  who
   observes the response and is in possession of the users' secret key
   (which doesn't change from login to  login)  can  use  the  key  to
   decrypt the response and obtain the single-use authentication data.
   This is dependent on the SAM technology used.

   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



Hornstein, Renard, Newman, Zorn                              [Page 12]





INTERNET-DRAFT                                        October 27, 2003


   cryptography, it is possible that legitimate users  may  be  denied
   service.

   An attacker in possession of the users encryption key (again, which
   doesn't   change   from   login   to   login)   might  be  able  to
   generate/modify a SAM challenge and attach the  appropriate  check-
   sum.   This  affects  the  security  of both the send-encrypted-sad
   option and the must-pk-encrypt-sad option.


8. Expiration
   This Internet-Draft expires on April 27, 2004.


9. References

   [RFC1510]
        The Kerberos Network Authentication System; Kohl  and  Neuman;
        September 1993.

   [RFC1760]
        The S/Key One-Time Password System; Haller; February 1995

   [RFC1636]
        Report of IAB Workshop on Security in the  Internet  Architec-
        ture; Braden, Clark, Crocker and Huitema; June 1994

   [KCRYPTO]
        Encryption and Checksum Specifications for  Kerberos  5;  Rae-
        burn; May 2002



























Hornstein, Renard, Newman, Zorn                              [Page 13]





INTERNET-DRAFT                                        October 27, 2003


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
   USC/Information Sciences Institute
   4676 Admiralty Way #1001
   Marina del Rey, CA 90292-6695

   Phone: 310-822-1511
   EMail: bcn@isi.edu


   Glen Zorn
   Cisco Systems
   500 108th Ave NE
   Suite 500
   Bellevue, WA  98004

   Phone: 425-344-8113
   EMail: gwz@cisco.com





















Hornstein, Renard, Newman, Zorn                              [Page 14]





INTERNET-DRAFT                                        October 27, 2003


Appendix A - Key combination algorithm

   Definitions:

   prf - Pseudo-random function that outputs an octet string based  on
   an input key and a input octet string (defined in [KCRYPTO])

   ^   - Exclusive-OR operation

   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)









Hornstein, Renard, Newman, Zorn                              [Page 15]





INTERNET-DRAFT                                        October 27, 2003


   Appendix B - DES/3DES Key combination algorithm

      Definitions:

      DR - generate "random" data from an encryption key  (defined  in
      [KCRYPTO])

      n-fold - "stretches" or "shrinks" a sequence bits to a specified
      size (defined in [KCRYPTO])

      random-to-key - Generates an encryption key  from  random  input
      (defined in [KCRYPTO])

      DK - Derive-Key, defined in [KCRYPTO])

      CombineConstant - The ASCII encoding of  the  string  "combine",
      which is defined as the following byte string:

                   { 0x63 0x6f 0x6d 0x62 0x69 0x6e 0x65 }

      Note: | means "concatenate"

      Given two input keys, K1 and K2, the Combine-Key function is  as
      follows:

      R1 = DR(K1, n-fold(K2)) R2 = DR(K2, n-fold(K1))

      rnd = n-fold(R1 | R2)

      tkey = random-to-key(rnd)

      Combine-Key(K1, K2) = DK(tkey, CombineConstant)

























Hornstein, Renard, Newman, Zorn                              [Page 16]