Update gnulib files.

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

INTERNET-DRAFT                                         Clifford Neuman
<draft-ietf-cat-kerberos-passwords-00.txt>                         ISI
Updates: RFC 1510                                            Glen Zorn
November 28, 1994                                CyberSAFE Corporation



               Integrating One-time Passwords 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-00.txt>, and expires June 3, 1995.
   Please send comments to the authors.


1. Abstract

   This document defines extensions to the Kerberos protocol  specifi-
   cation  (RFC  1510,  "The  Kerberos  Network Authentication Service
   (V5)", September 1993) which provide a method by which a variety of
   one-time  password mechanisms may be supported within the protocol.
   The method defined specifies a standard fashion in which the preau-
   thentication data and error data fields in Kerberos messages may be
   used to transport one-time password data.


2. Motivation
   One-time (or single use) passwords are, as the name suggests, pass-
   words  which may be used at most once as a means of authentication.
   Several one-time password mechanisms are  currently  in  widespread
   use,  including  hardware-based schemes from vendors such as Enigma
   Logic, Digital Pathways and Security  Dynamics  and  software-based
   mechanisms   like  S/Key.   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



Neuman & Zorn                                                 [Page 1]
\f
INTERNET-DRAFT                                       November 28, 1994


   the one-time password. Some tokens require the user to  enter  data
   into  the device.  This input may take the form of a Personal Iden-
   tification Number (PIN), a server  generated  challenge  string  or
   both.   The  token  uses  the challenge string to help generate the
   single-use password.  Other tokens do not use a  challenge-response
   technique,  instead spontaneously generating a new, unique password
   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 Activity Board has encouraged the
   use of one-time passwords to improve Internet security.

   The popularity of the  Kerberos  authentication  protocol  is  also
   increasing,  and with it the demand for the integration of one-time
   password technology with it.  Several currently available implemen-
   tations  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 represents an attempt to remedy  that
   problem.   For  the sake of brevity, "one-time password" will often
   be abbreviated to "passcode" in the remainder of this document.


3. Generic Approach - Two Models

   As outlined above, there are  essentially  two  types  of  passcode
   mechanisms: challenge/response and time-based.  In order to support
   challenge/response mechanisms, the Kerberos Key Distribution Center
   (KDC)  must  communicate  the  appropriate  challenge string to the
   user,   via    some    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.   Note,  however,  that the KDC is not
   required to know which mode the client is using, nor is the  client
   required  to  support  both  modes: if the client supports just the
   challenge/response model, the protocol  will  still  work  (at  the
   expense of one extra exchange of messages with the KDC).


3.1 Challenge/Response Model

   The client begins with an initial KRB_AS_REQ message  to  the  KDC,
   using   whatever   form   of  preauthentication  is  common  (none,
   PA_ENC_TIMESTAMP (encrypted timestamp),  PA_OSF_DCE  (DCE),  etc.).
   Depending  on  the  type of preauthentication used, the user may or
   may not be prompted at this time for  her  Kerberos  password.   If
   (for  example)  encrypted timestamp preauthentication is used, then
   the  user  will  be  prompted;   on   the   other   hand,   if   no



Neuman & Zorn                                                 [Page 2]
\f
INTERNET-DRAFT                                       November 28, 1994


   preauthentication  is  in  use  the  prompt for the password may be
   deferred.  Note that the use of preauthentication here may allow an
   offline guessing attack against the Kerberos password separate from
   the one-time passcode, but that if a passcode is required, then the
   password by itself is not sufficient for authentication.

   If the client is required to present a one time passcode, 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 contain-
   ing the ASN.1 structure that is a sequence of PA-DATA fields.

   If the type  of  one  of  the  PA-DATA  fields  is  PA-OT-PASSCODE-
   REDIRECT-TO-PRIMARY,  the  client should re-execute the authentica-
   tion protocol from the beginning, directing messages to the primary
   KDC  for  the realm.  This is done to allow some methods to require
   that a single KDC be used for passcode authentication if tight syn-
   chronization  is  needed between all replicas, and the KDC database
   propogation code does not provide such synchronization.

   Otherwise, if one  of  the  PA-DATA  fields  has  the  type  PA-OT-
   PASSCODE-CHALLENGE, the exchange will continue as described in sec-
   tion 4, below; otherwise, the KDC will respond as specified by  RFC
   1510.


3.2 Time-based Model

   For mechanisms where no challenge is required,  the  user  (or  the
   client  software  being utilized) may or may not know whether a one
   time password is required.  If it does not know, then  the  initial
   exchange  may  proceed  as  above.   If it is known that a one time
   password is required then the first exchange can be skipped and the
   authentication will continue as follows.


4. Authentication Using Passcodes

   Prior to performing preauthentication using a single use  password,
   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 3.1). The client does NOT need to know
   the  specific kind of passcode in use other than to know whether it
   requires a challenge.  This means that a client supporting one-time
   passwords  will  be able to work with new methods without modifica-
   tion.

   If a KRB_ERROR message was received from the KDC indicating that  a
   passcode  is  required, that message includes in its e-data field a
   PA-DATA structure that encodes information about the passcode  that
   is  needed.   This includes whether a challenge is required, if so,
   what the challenge is, and informational data  about  the  type  of
   passcode  that  is needed, and how to prompt for the passcode.  The
   type of the passcode is informational only and does not affect  the



Neuman & Zorn                                                 [Page 3]
\f
INTERNET-DRAFT                                       November 28, 1994


   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 passcode challenge is:

          PA-OT-PASSCODE-CHALLENGE ::= SEQUENCE {
              otpc-type                 INTEGER,
              otpc-flags                OTPCFlags,
              otpc-type-name            GeneralString OPTIONAL,
              otpc-track-id             GeneralString OPTIONAL,
              otpc-challenge-label      GeneralString OPTIONAL,
              otpc-challenge            GeneralString OPTIONAL,
              otpc-response-prompt      GeneralString OPTIONAL,
              otpc-pk-for-passcode      EncryptionKey OPTIONAL,
              otpc-nonce                INTEGER OPTIONAL,
              otpc-cksum                Checksum OPTIONAL
          }

          OTPCFlags ::= BIT STRING {
              use-passcode-as-key(0),
              send-encrypted-passcode(1),
              must-pk-encrypt-passcode(2)
          }

   The otpc-type field is informational only, but it must be specified
   and  otpc-type  values  must  be  registered.   The values that are
   presently defined are:

          PA_OTPC_TYPE_ENIGMA           1   -- Enigma Logic
          PA_OTPC_TYPE_DIGI_PATH        2   -- Digital Pathways
          PA_OTPC_TYPE_SKEY_K0          3   -- S/Key where KDC has key 0
          PA_OTPC_TYPE_SKEY             4   -- Traditional S/Key
          PA_OTPC_TYPE_SECURID          5   -- Security Dynamics

   PA_OTPC_TYPE_ENIGMA,           PA_OTPC_TYPE_DIGI_PATH           and
   PA_OTPC_TYPE_SECURID are popular token cards.

   [NOTE: It will probably be necessary to fine-tune this list,  since
   some  vendors offer more than one type of device, each of which may
   require a different algorithm for verification.]

   PA_OTPC_TYPE_SKEY is the traditional S/Key protocol, in  which  the
   KDC  will not know the passcode.  PA_OTPC_TYPE_SKEY_K0 is a variant
   of S/Key that uses the same passcodes 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 KDC to generate the the  correct
   passcode.

   [NOTE: Using PA_OTPC_TYPE_SKEY_K0 gives up one advantage of  S/Key,
   e.g., that the information needed to generate the key not be stored
   on the host, but since the KDC is assumed to be  more  secure  than
   other  hosts  on  the network, it may be acceptable to give up this
   advantage in some situations.  The advantage of this S/Key  variant



Neuman & Zorn                                                 [Page 4]
\f
INTERNET-DRAFT                                       November 28, 1994


   is  that  security  of  the  network protocol is stronger since the
   passcode is known by the KDC and can be used as part of the  encyp-
   tion  key,  rather  than  being sent protected by an encryption key
   that has been subject to possible prior  exposure  to  an  attacker
   (see  the  limitations  section).  In any case, there seems to be a
   definite advantage to being  interoperable  with  the  S/Key  algo-
   rithm.]

   The otpc-flags field indicates whether the passcode is known by the
   KDC (in which case it can be used as part of the encryption key for
   the response), or if it must be provided to the KDC in  a  recover-
   able  manner.  If it is known to the KDC, use-passcode-as-key indi-
   cates that the passcode 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.   If  the
   passcode is not known by the KDC, then send-encrypted-passcode will
   be set, indicating that the  passcode  must  be  sent  to  the  KDC
   encrypted  under  the  key  used  in the response.  If neither use-
   passcode-as-key nor send-encrypted-passcode are set, the client may
   assume  that  the KDC knows the passcode, but the Kerberos password
   should be used along with the passcode in  the  derivation  of  the
   encryption  key  (see  below).  If must-pk-encrypt-passcode is set,
   then the passcode must additionally be encrypted in the public  key
   returned  by  the  KDC in the otpc-pk-for-passcode field. Note that
   there are specific constraints  on  the  integrity  of  the  PA-OT-
   PASSCODE-CHALLENGE  when  some  of these options are specified.  In
   particular, if any of these flags are  specified,  a  crypyographic
   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.

   [NOTE: The flags (and their  interpretations)  provide  generality,
   but  complicate things considerably.  Should some be dropped in the
   interest of simplicity?]

   The optional otpc-type-name field is informational only.  It may be
   used  by  the  client to display a short description of the type of
   passcode required.

   The optional otpc-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 challenge response sent in  the
   subsequent  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 otpc-challenge-label field is informational and  optional.   If
   present,  a  client  may  choose to precede the presentation of the
   challenge with the label; however, it should not  be  used  if  the
   otpc-checksum  field  is empty, since in that case it may have been
   modified by an adversary.  For example, if the challenge is  135773
   and the string in the otpc-challenge-label field is "Enter the fol-
   lowing number on your card", the client may choose  to  display  to



Neuman & Zorn                                                 [Page 5]
\f
INTERNET-DRAFT                                       November 28, 1994


   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

   The optional otpc-challenge field contains a string  that  will  be
   needed  by  the user to generate a suitable response.  If the otpc-
   challenge field is left out, it indicates that the type of passcode
   in  use  does not require a challenge, and that the authorized user
   should be able to enter the correct passcode without one.   If  the
   otpc-challenge  field  is  present, it is the data that is input to
   the one time password mechanism to generate the response.

   The otpc-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
   otpc-checksum  field  is  empty,  since in that case the prompt may
   have been modified by an adversary.  Otherwise the prompt displayed
   will be hardcoded into the application, such as

          Passcode:

   [NOTE: Are the otpc-challenge-label and otpc-response-prompt fields
   useful if the KRB_ERROR message isn't integrity-protected?]

   otpc-pk-for-passcode is an optional field containing a  public  key
   generated by the KDC and returned to the client for use in encrypt-
   ing the passcode before returning it to  the  server.   This  addi-
   tional  encryption  is intended for use with passcode mechanisms in
   which the passcode is not known by the  KDC.   Its  purpose  is  to
   prevent  an  attacker  who  has already obtained the users password
   from also obtaining the passcode, which might otherwise be possible
   by  eavesdropping  on  the  exchange  (if  the  passcode  had  been
   encrypted solely  in  the  user's  password).   If  this  field  is
   present, its integrity must be assured by a checksum.

   [NOTE: The otpc-pk-for-passcode field and its  use  are  not  fully
   specified.  This is basically a placeholder for future use.]


   The otpc-nonce field is optional.  If present, it should conform to
   the  specification of the nonce field in a KRB_KDC_REQ message (see
   RFC 1510, section 5.4.1).

   The optional otpc-cksum field contains a cryptographic checksum  of
   the preceding fields, protected using the same key as that used for
   preauthentication in the  intial  KRB_AS_REQ  message.   While  any
   secure  checksum method may be used, the RSA-MD5-DES type is recom-
   mended.  This  field  should  always  be  present  if  the  initial
   KRB_AS_REQ    message    included    a    type   of   cryptographic



Neuman & Zorn                                                 [Page 6]
\f
INTERNET-DRAFT                                       November 28, 1994


   preauthentication (such as PA_ENC_TIMESTAMP).  If the  intial  mes-
   sage  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: if the otpc-
   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  instructions  to  be
   displayed  to the user in the prompt string, or allow the denial of
   service through the proffering of an  invalid  challenge.   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: 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 available material which
   enables an offline  guessing  attack  against  the  key.   Is  this
   acceptable?   Should  the use of the otpc-cksum field be allowed or
   prohibited  in  the  absence  of  cryptographic  preauthentication?
   Should  it  be  left  as  a  matter  of  realm policy?  Feedback is
   encouraged.]

   If the client is performing passcode preauthentication in the  ini-
   tial  message,  without receipt of a PA-OT-PASSCODE-CHALLENGE (i.e.
   without waiting for the KRB_ERROR message), and the passcode scheme
   in use does not require a challenge, the client will prompt for the
   passcode in an application-specific manner.

   Once the user has been prompted for and entered passcode and possi-
   bly  the  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
       passcode  by  runnning  each through the string_to_key function
       (see RFC 1510,  Section  6.3.4)  separately,  then  XORing  the
       results.

       If the use-passcode-as-key flag is set and the integrity of the
       PA-OT-PASSCODE-CHALLENGE PADATA field can be verified using the
       otpc-cksum  field,  then  the  passcode  is  run  through   the
       string_to_key function and the result is used as the encryption
       key for the request.  WARNING: the use of a  passcode  in  this
       manner  is  NOT recommended unless the range of the passcode is
       large enough to make an exhaustive off-line search  impractical
       and the risks involved in the use of a passcode alone are fully
       considered.  Also, note that without the availabilty 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-OT-PASSCODE-CHALLENGE  PADATA  field  are  based on
       either public key cryptography or the KDC's  knowledge  of  the
       passcode  itself.   In  the latter case, the client must obtain
       the passcode from the user and use it to verify  the  integrity



Neuman & Zorn                                                 [Page 7]
\f
INTERNET-DRAFT                                       November 28, 1994


       of the challenge before the new KRB_AS_REQ message is sent.

       If the otpc-pk-for-passcode field is not empty, the client sup-
       ports  public key cryptography, and the integrity of the PA-OT-
       PASSCODE-CHALLENGE PADATA  field  can  be  verified,  then  the
       response  will  be  encrypted twice: first, in the key from the
       otpc-pk-for-passcode field; and next, in the  conventional  key
       obtained in the manner described above.

The client will then send another KRB_AS_REQ message to the  KDC,  but
with  a  padata  field  with  padata-type equal to PA-OTP-RESPONSE and
padata-value defined as follows:

       PA-OT-PASSCODE-RESPONSE ::= SEQUENCE {
           otpc-type                 INTEGER,
           otpc-track-id             GeneralString OPTIONAL,
           otpc-enc-nonce-or-ts      EncryptedData
                                      -- PA-ENC-PASSCODE-RESPONSE-ENC,
           otpc-nonce                INTEGER OPTIONAL
           otpc-patimestamp          KerberosTime OPTIONAL
       }

       PA-ENC-PASSCODE-RESPONSE-ENC ::= CHOICE {
           otpc-nonce                INTEGER,
           SEQUENCE {
                patimestamp               KerberosTime,
                pausec                    INTEGER
           }
       }

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

If an error reply was received, the otpc-type  field  will  contain  a
copy of the otpc-type field from the error message.  If the otpc-nonce
field was present in the KRB_ERROR message, then the  PA-ENC-PASSCODE-
RESPONSE-ENC  structure  returned  to the KDC will include that value,
encrypted as described above, the otpc_nonce field in  the  KRB_AS_REQ
message  will contain a plaintext copy of the same value and the otpc-
patimestamp field of the message will be empty. If either no KRB_ERROR
message  was received or the otpc-nonce field was omitted from it, the
encrypted data will contain a timestamp encrypted in the same  manner,
the  otpc-patimestamp  field  will  contain an unencrypted copy of the
same value, and the otpc-nonce field will be empty.

Upon receipt the KDC validates this PADATA in much the same  way  that
it  validates  the  PA-ENC-TS  preauthentication method except that it
determines the appropriate passcode and uses it (possibly in  conjunc-
tion 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 otpc-track-id field to encode its
state, the KDC is responsible for including information in that  field
to prevent modification or replay by an attacker.



Neuman & Zorn                                                 [Page 8]
\f
INTERNET-DRAFT                                       November 28, 1994


The rest of the processing of the request  proceeds  normally,  except
that  instead of being encrypted in the users password, the KRB_AS_REP
message is encrypted in the key obtained above.


5. Limitations

   If the passcode implementation on the KDC results in the sending of
   PA-OT-PASSCODE-REDIRECT-TO-PRIMARY, the availability of the KDC for
   clients using such a passcode is limited to  the  availablility  of
   the  single primary KDC, and the benefits of replication of the KDC
   are lost.

   Passcode implementations requiring the use of  the  send-encrypted-
   passcode option are discouraged as their use on the network is less
   secure than the case where a combination of the users password  and
   passcode  is  used  as the encryption key.  In particular, when the
   send-encrypted-passcode option is used, an  attacker  who  observes
   the  response  and  is  in  possession of the users' encryption key
   (which doesn't change from login to  login)  can  use  the  key  do
   decrypt the response and obtain the passcode.

   It also appears to be the case that an attacker  in  possession  of
   the users encryption key (again, which doesn't change from login to
   login) would be able to generate/modify a  passcode  challenge  and
   attach the appropriate checksum.  This affects the security of both
   the send-encrypted-passcode option and the must-pk-encrypt  option.
   We  would  like  input  on  whether these options should be dropped
   entirely, whether there is sufficient need  or  potential  need  to
   integrate such forms of passcodes that we leave it but with a warn-
   ing, or whether there are better options for  integrity  protecting
   the challenge (e.g.  eventually a digital signature generated using
   the KDC's RSA private key, but that introduces the problem  of  the
   certification of the KDC's public key).


6. Expiration

   This Internet-Draft expires on June 3, 1995.


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



Neuman & Zorn                                                 [Page 9]
\f
INTERNET-DRAFT                                       November 28, 1994


   2443 152nd Avenue N.E.
   Redmond, WA 98052

   Phone: 206-883-8721
   EMail: gwz@cybersafe.com




















































Neuman & Zorn                                                [Page 10]
\f