Update gnulib files.

[shishi.git] / doc / specifications / draft-ietf-cat-kerberos-passwords-04.txt

INTERNET-DRAFT                                         Clifford Neuman
<draft-ietf-cat-kerberos-passwords-04.txt>                         ISI
Updates: RFC 1510                                            Glen Zorn
November 18, 1998                                Microsoft Corporation
                                                      Jonathan Trostle
                                                 CyberSAFE Corporation
                                                         Ken Hornstein
                                                               ITT/NRL



      Integrating Single-use Authentication Mechanisms with Kerberos


0. Status Of this Memo
   This document is an Internet-Draft.   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-cat-kerberos-passwords-04.txt>,  and   expires  May 11,
   1999.  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 cer-
   tain unique information is held by a principal.   This  information



Neuman, Zorn, Hornstein                                       [Page 1]





INTERNET-DRAFT                                       November 18, 1998


   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  prin-
   cipal  might  input  a one-time password (in any of several forms);
   the knowledge of  this  one-time  password  is  taken  to  indicate
   knowledge of the principal's secret passphrase.  Similarly, the SPD
   may or may not contain the provided single-use authentication 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  process  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  encryp-
   tion 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,  Digital  Pathways  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  challenge  string  or  both.   Other tokens do not use a
   challenge-response technique, instead spontaneously generating  new
   and unique authentication data every few seconds.  These tokens are
   usually time-synchronized with a server.  The use of one-time pass-
   words  and  token cards as an authentication mechanism has steadily
   increased over the past few years; in addition, the Internet Archi-
   tecture  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
   either the generation or verification of SAM data,  since  this  is



Neuman, Zorn, Hornstein                                       [Page 2]





INTERNET-DRAFT                                       November 18, 1998


   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.


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 eavesdopping attacker to capture
   a valid S/Key passcode and replay it to a KDC replica which had  an
   outdated iteration number.  In the time-based case, no challenge 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
   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



Neuman, Zorn, Hornstein                                       [Page 3]





INTERNET-DRAFT                                       November 18, 1998


   contain an encoded sequence of host addresses [RFC1510], from which
   the client must choose the KDC to be contacted next.

   Otherwise, if one of  the  PA-DATA  fields  has  the  type  PA-SAM-
   CHALLENGE,  the  exchange  will continue as described in section 5,
   below.


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. Authentication Using Passcodes
   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
   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.

















Neuman, Zorn, Hornstein                                       [Page 4]





INTERNET-DRAFT                                       November 18, 1998


   The ASN.1 definition for the SAM challenge is:

          PA-SAM-CHALLENGE ::= SEQUENCE {
              sam-type[0]                 INTEGER,
              sam-flags[1]                SAMFlags,
              sam-type-name[2]            GeneralString OPTIONAL,
              sam-track-id[3]             GeneralString OPTIONAL,
              sam-challenge-label[4]      GeneralString OPTIONAL,
              sam-challenge[5]            GeneralString OPTIONAL,
              sam-response-prompt[6]      GeneralString OPTIONAL,
              sam-pk-for-sad[7]           EncryptionKey OPTIONAL,
              sam-nonce[8]                INTEGER OPTIONAL,
              sam-cksum[9]                Checksum OPTIONAL
          }

          SAMFlags ::= BIT STRING {
              use-sad-as-key[0],
              send-encrypted-sad[1],
              must-pk-encrypt-sad[2]
          }

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



Neuman, Zorn, Hornstein                                       [Page 5]





INTERNET-DRAFT                                       November 18, 1998


   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 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 not be used, and that the principal also
   enter the Kerberos password, but for some situations,  presentation
   of  the SAD alone may be acceptable.  If the single-use authentica-
   tion data is not known (and cannot be generated or  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  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 Ker-
   beros  password  should  be  used  along  with  the passcode in the
   derivation  of  the  encryption  key  (see  below).   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.

   Note that there are specific constraints on the  integrity  of  the
   PA-SAM-CHALLENGE when some of these options are specified.  In par-
   ticular, if any of these flags are set,  a  cryptographic  checksum
   must  be present and verified.  If absent, or the checksum does not
   match the request, the challenge must be considered invalid and the
   user notified.

   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.

   The optional sam-track-id field may be returned by the KDC  in  the
   KRB_ERROR  message.   If present, the client should 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
   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.

   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



Neuman, Zorn, Hornstein                                       [Page 6]





INTERNET-DRAFT                                       November 18, 1998


   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

   If the sam-checksum field is empty the  sam-challenge-label  should
   be  ignored,  since  in  that  case it may have been modified by an
   adversary.  Internationalization is supported by allowing  customi-
   zation  of the challenge label and other strings on a per-principal
   basis.  Note that this character string  should  be  encoded  using
   UTF-8.

   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.

   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; however, it should not be  used  if  the
   sam-checksum field is empty, since in that case the prompt may have
   been modified by an adversary.  If this field is empty  the  prompt
   displayed will be hardcoded into the application, such as

          Passcode:

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

   The sam-nonce field is optional.  If present, it should conform  to
   the  specification  of  the  nonce  field  in a KRB_KDC_REQ message
   [RFC1510].

   The optional sam-cksum field contains a cryptographic  checksum  of
   the preceding fields, protected using the same key as that used for
   preauthentication in the initial  KRB_AS_REQ  message.   While  any
   secure  checksum method may be used, the RSA-MD5-DES type is recom-
   mended and must be supported by  the  client.   This  field  should
   always be present if the initial KRB_AS_REQ message included a form
   of cryptographic preauthentication (such as PA_ENC_TIMESTAMP).   If
   the  initial  message included preauthentication, but this field is
   missing in the response, the client should reject the response.  If
   this  field  is  present, the client should verify its correctness:



Neuman, Zorn, Hornstein                                       [Page 7]





INTERNET-DRAFT                                       November 18, 1998


   if the sam-cksum field is present in the KRB_ERROR message, but not
   verified  by  the  client,  then an attacker can change the message
   contents at will.  Such a change could  cause  unexpected  instruc-
   tions  to  be  displayed to the user in the prompt string, or allow
   the denial of service through the presentation of an invalid  chal-
   lenge.   Another  effect  of  a change might be to effect a limited
   chosen plaintext attack on the Kerberos password where the attacker
   picks the nonce, and the challenge.

   Note that it is possible for the KDC to  generate  a  cryptographic
   checksum  for  this message using the users' secret key even though
   no cryptographic  preauthentication  was  present  in  the  initial
   AS_REQ  message.  Doing so, however, makes material available which
   enables an offline guessing attack against that key.

   If the client is performing SAM preauthentication  in  the  initial
   message,  without receipt of a PA-SAM-CHALLENGE (i.e. without wait-
   ing 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).  The K1 and K2 are then combined to form
          a single key K in a manner specific to the type of key being
          generated.   For DES keys, K will be formed by XORing K1 and
          K2, then correcting the parity of K.  If the result  matches
          a  "weak" or "semiweak" key as described in the DES specifi-
          cation,  it  is  XORed   with   the   hexadecimal   constant
          00000000000000F0.

          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  PADATA  field  can  be  verified using the
          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 PADATA  field  are  based  on  either  public  key



Neuman, Zorn, Hornstein                                       [Page 8]





INTERNET-DRAFT                                       November 18, 1998


          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.

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

          PA-SAM-RESPONSE ::= SEQUENCE {
              sam-type[0]                 INTEGER,
              sam-flags[1]                SAMFlags,
              sam-track-id[2]             GeneralString OPTIONAL,
              sam-enc-key[3]              EncryptedData
                                             -- PA-ENC-SAM-KEY,
              sam-enc-nonce-or-ts[4]      EncryptedData
                                             -- PA-ENC-SAM-RESPONSE-ENC,
              sam-nonce[5]                INTEGER OPTIONAL,
              sam-patimestamp[6]          KerberosTime OPTIONAL
          }

              PA-ENC-SAM-KEY ::= SEQUENCE {
                           sam-key[0]                 EncryptionKey
              }

          PA-ENC-SAM-RESPONSE-ENC ::= SEQUENCE {
               sam-nonce[0]               INTEGER OPTIONAL,
               sam-timestamp[1]           KerberosTime OPTIONAL,
               sam-usec[2]                INTEGER OPTIONAL,
               sam-sad[3]            GeneralString OPTIONAL
          }

   The source of the data included in  the  PA-SAM-RESPONSE  structure
   depends upon whether or not a KRB_ERROR message was received by the
   client from the KDC.

   If an error reply was received, the sam-type and  sam-flags  fields
   will  contain copies of the same fields from the error message.  If
   the sam-nonce field was present in the KRB_ERROR message, then  the
   PA-ENC-SAM-RESPONSE-ENC  structure returned to the KDC will include
   that value, encrypted as described above, the nonce  field  in  the
   KRB_AS_REQ  message will contain a plaintext copy of the same value
   and the sam-timestamp field in the  PA-ENC-SAM-RESPONSE-ENC  struc-
   ture  will  be empty.  If a sam-timestamp is present in the PA-ENC-
   SAM-RESPONSE, the sam-patimestamp field must  be  supplied  in  the
   PA-SAM-RESPONSE.   If a KRB_ERROR message was received but the sam-
   nonce field was omitted from it, the encrypted data will contain  a
   timestamp  encrypted  in the same manner, the sam-patimestamp field



Neuman, Zorn, Hornstein                                       [Page 9]





INTERNET-DRAFT                                       November 18, 1998


   will contain an unencrypted copy of the same value,  and  the  sam-
   nonce  field will be empty.  In either case, if the send-encrypted-
   sad flag is set in the sam-flags field of the  error  message,  the
   sam-sad  field  must  contain the entered single-use authentication
   data.

   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.

   Note that is there is no sam-track-id in the request, it should  be
   omitted in the response.

   The sam-enc-key field is reserved for future use.

   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 KDC is responsible for including  informa-
   tion in that field to detect modification or replay by an attacker.

   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
   sam-type value, along with appropriate prompts  and/or  challenges.
   This  sequence  of  exchanges  will  continue  until authentication
   either succeeds or fails.


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




Neuman, Zorn, Hornstein                                      [Page 10]





INTERNET-DRAFT                                       November 18, 1998


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


7. Expiration
   This Internet-Draft expires on Feburary 11, 1999.


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





























Neuman, Zorn, Hornstein                                      [Page 11]





INTERNET-DRAFT                                       November 18, 1998


9. Authors' Addresses
   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
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   Phone: 206-703-1559
   EMail: glennz@microsoft.com


   Ken Hornstein
   ITT/US Naval Research Lab
   4555 Overlook Avenue
   Washington, DC 20375

   Phone: 202-404-4765
   EMail: kenh@cmf.nrl.navy.mil































Neuman, Zorn, Hornstein                                      [Page 12]