directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tbenn...@apache.org
Subject svn commit: r486187 [20/49] - in /directory/trunks/triplesec: ./ admin-api/ admin-api/src/ admin-api/src/main/ admin-api/src/main/java/ admin-api/src/main/java/org/ admin-api/src/main/java/org/safehaus/ admin-api/src/main/java/org/safehaus/triplesec/ a...
Date Tue, 12 Dec 2006 15:24:14 GMT
Added: directory/trunks/triplesec/src/site/xdoc/drafts/draft-ietf-krb-wg-kerberos-sam-03.txt
URL: http://svn.apache.org/viewvc/directory/trunks/triplesec/src/site/xdoc/drafts/draft-ietf-krb-wg-kerberos-sam-03.txt?view=auto&rev=486187
==============================================================================
--- directory/trunks/triplesec/src/site/xdoc/drafts/draft-ietf-krb-wg-kerberos-sam-03.txt
(added)
+++ directory/trunks/triplesec/src/site/xdoc/drafts/draft-ietf-krb-wg-kerberos-sam-03.txt
Tue Dec 12 07:23:31 2006
@@ -0,0 +1,1050 @@
+
+INTERNET-DRAFT                                           Ken Hornstein
+<draft-ietf-krb-wg-kerberos-sam-03.txt>      Naval Research Laboratory
+Updates: RFC 1510                                           Ken Renard
+July 15, 2004                                              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-03.txt>,  and  expires  January 19,
+   2005.  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                                           July 15, 2004
+
+
+   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                                           July 15, 2004
+
+
+   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                                           July 15, 2004
+
+
+   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                                           July 15, 2004
+
+
+   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                                           July 15, 2004
+
+
+       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                                           July 15, 2004
+
+
+   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                                           July 15, 2004
+
+
+   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                                           July 15, 2004
+
+
+   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                                           July 15, 2004
+
+
+          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                                           July 15, 2004
+
+
+   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                                           July 15, 2004
+
+
+   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                                           July 15, 2004
+
+
+   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 January 19, 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                                           July 15, 2004
+
+
+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                                           July 15, 2004
+
+
+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                                           July 15, 2004
+
+
+   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]
+



Mime
View raw message