Subject: GSS-API-Easy mechanism

From: Denis Pinkas <[email-masked]>
Date: Tue, 02 Mar 1999 09:33:43 +0100

A new draft has been posted to the I-D editor on last Thursday before the dead
line. However it has not yet been published. In order to allow the WG to get a
few extra days to review the document before the next meeting, hereafter is a
summary of the document as well as the whole document attached.

The GSS-API-Easy mechanism will help application programmers
to develop applications making use of GSS-API tokens and
can be seen as a first step before adopting techniques making
use of security infrastructures or security servers.

It is easy to deploy since it does not rely on the existence of a
security infrastructure nor the existence of a security server.

It enables unilateral and mutual authentication of peers
as well as per-message protections. It is based on the use
of an identifier and a passphrase shared between the client
and the server but uses a protocol where the passphrase
is never sent in the clear. In addition, this document describes a
protocol to change the passphrase.

After posting the draft, two editorial errors have been noticed:

1. On page 3, section 1.1.2. the sentence " Then an AuthConfirm is computed
applying N times the one-way  function" should be changed into " Then an
AuthConfirm is computed applying the one-way  function".

2. On page 12, section 5.3.2.2. the sentence " where confounder contains an 8
bytes random confounder and userText contains the user's provided text."
should be changed to : " where confounder contains an 8 bytes random
confounder and originalText contains the user's provided text."

Denis

INTERNET-DRAFT                                             J. Lebastard
IETF Common Authentication Technology WG                      D. Pinkas
<draft-ietf-cat-gsseasy-00.txt>                               Bull S.A.
                                                      February 24, 1999

                   The GSS-API-Easy Mechanism

STATUS OF THIS MEMO

   This document is an Internet-Draft and is in full conformance with
   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 documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Comments on this document should be sent to "[email-masked]", the
   IETF Common Authentication Technology WG discussion list.

ABSTRACT

   This document provides a description of a GSS-API mechanism usable
   through the Generic Security Service Application Program Interface 
   (as specified in Internet-Drafts [GSSV2] and [GSSV2-C]) that is 
   easy to deploy since it does not rely on the existence of a 
   security infrastructure nor the existence of a security server.

   The GSS-API-Easy mechanism enables unilateral and mutual 
   authentication of peers as well as per-message protections. It is 
   based on the use of an identifier and a passphrase shared between 
   the client and the server but uses a protocol where the passphrase 
   is never sent in the clear. In addition, this document describes a
   protocol to change the passphrase.

   This mechanism will help application programmers to develop 
   applications making use of GSS-API tokens and can be seen as a 
   first step before adopting techniques making use of security 
   infrastructures or security servers. 

Lebastard, Pinkas                                            [ Page 1 ]
Internet-Draft                 Document Expiration : September 25, 1999

GENERAL

   The first section of this Internet-Draft specifies the GSS-API-Easy
   authentication protocol. Section 2 describes the change passphrase
   protocol. Section 3 gives the list of supported security services.
   Section 4 specifies how session keys are established. Section 5 
   defines the GSS-API Token framing for this Mechanism. Section 6
   discusses naming issues. Section 7 lists some security
   considerations.

1. The authentication protocol

   The GSS-API-Easy mechanism is based on the use of a one-way
   cryptographic function. It does not use any authentication server.
   It requires that both peers (the client, acting as the initiator,
   and the server, acting as the acceptor) share the identifier of the
   client and a "PassPhrase".
   
   The term "PassPhrase" identifies a secret which contains more
   characters than usual passwords (sometimes limited to eight 
   characters) in order to lengthen password dictionary attacks. 
   In order to make such attacks even more difficult, the one-way
   function is used several times (e.g. ten thousands) during the
   authentication process.

   A Passkey is first locally derived using a one-way function 
   applied N times to both the client identifier and the passphrase.

      PassKey = (OWF)N (ClientName, PassPhrase)

   The number of iterations should be chosen by the client so that 
   it takes about 1/4 second on the client workstation to generate it.
   In practice, for a workstation, figures between 10.000 and 100.000
   iterations should be chosen.

   This means that the number of attacks per second is greatly reduced.
   Since the client identifier is part of the computation, dictionary
   attacks have to be targeted towards a given user.

1.1. Authentication Mechanism

   The Authentication mechanism uses unique numbers composed of a time
   and a random number. It is based on the use of loosely synchronized
   clocks and has the advantage of allowing to perform a client
   authentication in one exchange while being resistant to replay
   attacks.

1.1.1. Unilateral Authentication

   The client first picks up the local time and generates a random 
   number which is used as a confounder.

Lebastard, Pinkas                                            [ Page 2 ]
Internet-Draft                 Document Expiration : September 25, 1999

   Then, an AuthProof is computed applying the one-way function to the
   concatenation of the computed PassKey, the Confounder, the current
   local time, the name of the server and the PassKey :

      AuthProof = OWF (PassKey, Time-C, Confounder-C, ServerName,
                       PassKey)

   The GSS-API Context establishment token defined in section 5 of this
   document includes the Confounder, the local time, the number of 
   iterations N of the OWF, the OWF algorithm identifier, both peers
   names and AuthProof items.

   If no error occurs while building that token, GSS_InitSecContext
   returns GSS_S_COMPLETE to the invoker.

   Upon reception of the GSS-API context establishment token, the
   server combines the Confounder and Time item in a "UniqueNumber".
   The server uses this UniqueNumber to perform a context establishment
   replay detection.

   If that replay check fails (i.e. if that UniqueNumber was not
   previously received), the server obtains OWF and N from the context 
   token. It computes the PassKey using the proper PassPhrase. It then 
   uses the received Confounder and Time to compute an AuthVerif :

      AuthVerif = OWF (PassKey, Time-C, Confounder-C, ServerName,
                       PassKey)

   The authentication of the client succeeds if AuthVerif is the same
   as the received AuthProof.

1.1.2. Mutual Authentication

   Mutual authentication process requires an additional step. At the
   the client side, the mutual authentication process differs in two
   ways : a) the Context establishment token includes the
   Mutual Authentication flag, and b) the GSS_InitSecContext() routine
   returns GSS_S_CONTINUE_NEEDED to the invoker.
   
   At the server side, the acceptor authenticates himself to the client
   using a similar process.
   
   The server generates a random number which is used as a confounder. 
   Then an AuthConfirm is computed applying N times the one-way 
   function to the concatenation of the computed PassKey, the
   Confounder-S, the Time-C, Confounder-C, the name of the server and
   the PassKey :
   
      AuthConfirm = OWF (PassKey, Confounder-S, Time-C, Confounder-C,
                         ServerName, PassKey)

   Note that the presence of the server name prevents the replay of 
   the authentication token on a different server that would be sharing

Lebastard, Pinkas                                            [ Page 3 ]
Internet-Draft                 Document Expiration : September 25, 1999

   the same client identifier and passphrase.

   The GSS-API Context establishment return token defined in section 5 
   of this document includes the Confounder-S and AuthConfirm items. If
   no error occurs while building that token, GSS_AcceptSecContext
   returns GSS_S_COMPLETE to the invoker.

   Upon reception of the GSS-API context establishment return token,
   the client combines the Confounder-S and Time-C items in a 
   "UniqueNumber". The client uses this UniqueNumber to perform a 
   context establishment replay detection.

   If that replay check fails (i.e. if that UniqueNumber was not
   previously received), the client uses the received Confounder-S and
   Time-C to compute an AuthVerif :

     AuthVerif = OWF (PassKey, Confounder-S, Time-C, Confounder-C, 
                      ServerName, PassKey)

   The authentication of the client succeeds if AuthVerif is the same 
   as the received AuthConfirm sent by the server.

2. Change PassPhrase Mechanism

   When a user wishes to change the PassPhrase he shares with a peer,
   he simply needs to send a changepassphrase token that contains 
   both the current and the new PassPhrase encrypted with a key 
   derived from the current PassKey. This change passphrase operation 
   is performed at any time after the context establishment process.
   
   The scheme used for message privacy (see section 5.3.2.2) is used
   for encrypting the passphrase using the current confidentiality
   dialogue key.

   The change operation will be accepted by the target if three
   conditions occur : the seal is correct, the current passphrase sent
   by the client matches the current passphrase known to the target,
   the new passphrase is sufficiently different from the current and
   previous passphrases.
   
   If the change is accepted by the target then the change passphrase
   acceptance token is returned. Otherwise an error token is returned.

   If mutual authentication is being used for the context establishment
   the target may indicate in a secondary status either that the
   credentials are going to expire soon or that they have expired. In
   the former case the client can still use subsequent MIC or WRAP
   tokens. In the later case, the client has to send a changepassphrase
   token otherwise MIC and WRAP tokens will be rejected.

3. Security Services

Lebastard, Pinkas                                            [ Page 4 ]
Internet-Draft                 Document Expiration : September 25, 1999

   The GSS-API-Easy Mechanism supports mutual and anonymous
   authentication. The integrity, privacy, replay detection and out-of-
   sequence detection security services are provided for user messages
   protection. GSS-API-Easy Mechanism also supports the inter-process
   context transfer and the use of incomplete contexts. Refer to
   [GSSV2-C] for a definition of this security services.
   
   GSS-API-Easy does not support delegation.
   
   Support of anonymity by the GSS-API-Easy Mechanism complies with
   [GSSV2-C]: ''In addition to informing the application that a context
   is established anonymously (via the ret_flags outputs from
   gss_init_sec_context and gss_accept_sec_context), the optional
   src_name output from gss_accept_sec_context and gss_inquire_context
   will, for such contexts, return a reserved internal-form name,
   defined by the implementation. When presented to gss_display_name,
   this reserved internal-form name will result in a printable name
   that is syntactically distinguishable from any valid principal name
   supported by the implementation, associated with a name-type object
   identifier with the value GSS_C_NT_ANONYMOUS (...). For example, the
   string "<anonymous>" might be a good choice, if no valid principal
   name supported by the implementation can begin with "<" and end with
   ">". ''
   
   Channel bindings are not used by the GSS-API-Easy GSS-API mechanism:
   they are therefore not transmitted in the context establishment 
   tokens and any channel bindings provided to GSS-API routine calls
   are ignored by the GSS-API-Easy Mechanism implementation.

4. Session Keys

   The initiator (resp. acceptor) computes separate integrity and 
   confidentiality dialogue keys upon successful completion of 
   GSS_InitSecContext (resp. GSS_AcceptSecContext) routine call.

   The Integrity Dialogue Key is computed using :

     IDK = OWF ( PassKey, server-name, Time-C, Confounder-C, PassKey )

   The Confidentiality Dialogue Key is computed using :

     CDK = OWF ( PassKey, server-name, Confounder-C, Time-C, PassKey )

   It is to be noted that both dialogue keys may be computed at the 
   client side if GSS_InitSecContext routine returns 
   GSS_S_CONTINUE_NEEDED in case of mutual authentication. This allows 
   the GSS-API-Easy Mechanism to support the GSS_C_PROT_READY_FLAG.

5. GSS-API Token Formats

   This section discusses protocol-visible characteristics of the
   GSS-API-Easy GSS-API mechanism ; it defines elements of protocol for
   interoperability and is independent of language bindings per

Lebastard, Pinkas                                            [ Page 5 ]
Internet-Draft                 Document Expiration : September 25, 1999

   [GSSV2-C].

   Tokens transferred between GSS-API peers (for security context
   management, error and per-message protection purposes) are defined.

   The GSS-API-Easy GSS-API mechanism as defined in this and any
   successor memos will be identified with the following Object
   Identifier :

   { 1(iso), 3(org), 6(dod), 1(internet), 5(security), 5(mechanism),
     3(gss-api-easy) }
   [T.B.C.]

   Per [GSSV2], section 3.1, the initial context establishment token is
   enclosed within framing as follows :

   InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE {
     thisMech           MechType,
                        -- MechType is OBJECT IDENTIFIER
                        -- representing GSS-API-Easy
     innerContextToken  ANY DEFINED BY thisMech
                        -- contents mechanism-specific
                        -- ASN.1 structure not required
   }

   The above framing is applied to all tokens emitted by the
   GSS-API-Easy GSS-API mechanism, including change passphrase, error
   and per-message tokens, not just to the initial token in a context
   establishment sequence. While not required by [GSSV2], this enables
   implementations to perform enhanced error-checking.
   
   Per [GSSV2], GSS_DeleteSecContext does not produce any token.

   The innerContextToken consists in the BER encoding of the
   GssApiEasyToken ASN.1 data structure below :

   GssApiEasyToken ::= SEQUENCE {
     tokenType      [0] ENUMERATED {
                          INIT-Req-Token   (0),
                          INIT-Resp-Token  (1),
                          PASS-Req-Token   (2),
                          PASS-Resp-Token  (3),
                          MIC-Token        (4),
                          WRAP-Token       (5),
                          ERR-Token        (6)
     },
     tokenContents  [1] CHOICE {
       initReqToken     [0] InitReqToken,
       initRespToken    [1] InitRespToken,
       passReqToken     [2] PassReqToken,
       passRespToken    [3] PassRespToken,
       micToken         [4] MicToken,
       wrapToken        [5] WrapToken,
       errToken         [6] ErrToken

Lebastard, Pinkas                                            [ Page 6 ]
Internet-Draft                 Document Expiration : September 25, 1999

     }
   }

5.1. Context Establishment Tokens

5.1.1. Initial Token

   The initial context establishment token contains the above
   GssApiEasyToken data structure with tokenType set to
   INIT-Req-Token and tokenContents set to the InitReqToken data
   structure defined as :

   InitReqToken ::= SEQUENCE {
     initiatorName   [0] OCTET STRING,
     targetName      [1] OCTET STRING,
     contextFlags    [2] BIT STRING {
                           mutual           (2),
                           replay           (3),
                           sequence         (4),
                           confidentiality  (5),
                           anonymity        (6)
                         },
     timeStamp       [3] UTCTime,
     confounder      [4] OCTET STRING,
     owfId           [5] ENUMERATED {
                           sha1            (1),
                           md5             (2)
                         } OPTIONAL,
     owfIterations   [6] INTEGER OPTIONAL,
     authData        [7] OCTET STRING
   }

   The authData field contains the result of the computation of the
   OWF on the BER-encoding of the following AuthProofData item :

   AuthProofData ::= SEQUENCE {
     passKey           [0] OCTET STRING,
     timeC             [1] UTCTime,
     confounderC       [2] OCTET STRING,
     serverName        [3] OCTET STRING,
     passKey           [4] OCTET STRING
   }

   where passKey contains the result of N computations of the OWF on
   the BER-encoding of the following PassKeyData item :

   PassKeyData ::= SEQUENCE {
     clientName      [0] OCTET STRING,
     passPhrase      [1] OCTET STRING
   }

   The ClientName item used in the computation of the PassKey uses the
   content of the above initiatorName field.

Lebastard, Pinkas                                            [ Page 7 ]
Internet-Draft                 Document Expiration : September 25, 1999

   The ServerName item used in the computation of Authproof uses the
   content of the above targetName field.

   The contextFlags bit vector included in the initial context
   establishment token corresponds to the service flags as defined in
   [GSSV2] :

     GSS_C_DELEG_FLAG        1
     GSS_C_MUTUAL_FLAG       2
     GSS_C_REPLAY_FLAG       4
     GSS_C_SEQUENCE_FLAG     8
     GSS_C_CONF_FLAG        16
     GSS_C_INTEG_FLAG       32
     GSS_C_ANON_FLAG        64
     GSS_C_PROT_READY_FLAG 128
     GSS_C_TRANS_FLAG      256

   As said before, GSS-API-Easy GSS-API mechanism does not support the
   delegation service.

5.1.2. Authentication Response Token

   Applications requiring confirmation that their authentication was
   successful should request mutual authentication, resulting in a
   "mutual" indication within the contextFlags of the AuthToken.

   In response to such a request, the target replies to the initiator 
   with a token containing an GssApiEasyToken data structure where 
   tokenType is set to INIT-Resp-Token and tokenContents set to the
   InitRespToken data structure defined as :
   
   InitRespToken ::= SEQUENCE {
     confounderS     [0] OCTET STRING,
     authData        [1] OCTET STRING
   }

   In that token, the confounderS is a new randomly generated
   confounder and authData contains the result of the OWF on the BER-
   encoding of the following AuthVerifData :

   AuthVerifData ::= SEQUENCE {
     passKey           [0] OCTET STRING,
     confounderS       [1] OCTET STRING,
     timeC             [2] UTCTime,
     confounderC       [3] OCTET STRING,
     serverName        [4] OCTET STRING,
     passKey           [5] OCTET STRING
   }

   where timeC, confounderC and serverName are retrieved from the
   incoming InitReqToken, and passKey is computed as described in the
   above section 5.1.1.

5.2. Change PassPhrase Tokens

Lebastard, Pinkas                                            [ Page 8 ]
Internet-Draft                 Document Expiration : September 25, 1999

   The change passphrase procedure may occur at any time after the
   secure context establishment, i.e. once the session keys are
   established at both sides. Though these tokens are not produced
   by GSS-API routine calls, they use the GSS-API token framing
   defined in [GSSV2].

5.2.1. Change PassPhrase Request

   The change passphrase token contains the above GssApiEasyToken
   structure with tokenType set to PASS-Req-Token and tokenContents
   set to the PassReqToken data structure defined as :
   
   PassReqToken ::= SEQUENCE {
     passPhraseData      [0] OCTET STRING,
     seal                [1] OCTET STRING
   }
   
   where passPhraseData contains the encrypted BER-encoding of the
   following data structure :
   
   PassPhraseData ::= SEQUENCE {
     confounder          [0] OCTET STRING,
     currentPassPhrase   [1] OCTET STRING,
     newPassPhrase       [2] OCTET STRING
   }
   
   where confounder contains a random 8 bytes array.
   
   The encryption rule used during the change passphrase operation is
   the rule described for privacy WRAP token in section 5.3.2.2. of
   this document.
   
   The above seal field is computed on the passPhraseData item using
   the rule described for integrity WRAP token in section 5.3.2.1. of
   this document.

5.2.2. Change PassPhrase Response

   Upon reception of a change passphrase request, a peers verifies the
   seal of the PassPhraseToken and decrypts the PassPhraseData. If
   the newPassPhrase matches local passphrase policy (length and
   character set), then a new passphrase acceptance token is returned
   to the emitter. This token consists in an GssApiEasyToken with
   tokenType set to PASS-Resp-Token and tokenContents contains the
   PassRespToken data item defined as :
   
     PassRespToken ::= OCTET STRING
     
   That token contains the MIC of the above PassReqToken. That
   MIC is computed using the rule described for MIC Token in section
   5.3.1 of this document.
   
   In case of error, an Error Token is returned to the emitter of the

Lebastard, Pinkas                                            [ Page 9 ]
Internet-Draft                 Document Expiration : September 25, 1999

   change passphrase request. See section 5.4 of this document for
   detailed error status.

5.3. Per-Message Tokens

   Two classes of tokens are defined in this section : "MIC" tokens,
   emitted by calls to GSS_GetMIC() and consumed by calls to
   GSS_VerifyMIC(), and "WRAP" tokens, emitted by calls to GSS_Wrap()
   and consumed by calls to GSS_Unwrap().

5.3.1. MIC Tokens

   Use of the GSS_GetMIC() call yields a token, separated from the user
   data being protected, which can be used to verify the integrity of
   that data as received. For MIC tokens, tokenType is set to MIC-Token
   and tokenContents is set to the following MicToken :
   
   MicToken ::= SEQUENCE {
     seqNumber   [0] INTEGER OPTIONAL,
     mic         [1] OCTET STRING
   }
   
   The mic field is computed using the following formula :
        
      mic = OWF ( IDK, Data-Encoding, IDK )
          
   where Data-Encoding is the BER encoding of the MicData item :
   
   MicData ::= SEQUENCE {
     seqNumber   [0] INTEGER OPTIONAL,
     userText    [1] OCTET STRING
   }
     
   where userText contains the provided user message and its sequence
   number if GSS_C_SEQUENCE_FLAG is active for the current context.
   
   The OWF used to compute the mic is the same as the OWF used during
   the secure context establishment.
   
   Upon reception of a MicToken, the peer BER-encodes a MicData item
   with userText set to the provided user's text and seqNumber set to
   the received sequence number if GSS_C_SEQUENCE_FLAG is active for
   the current context. It then computes a seal with the above formula
   and verifies that this seal matches the received mic.

5.3.2. WRAP Tokens

   Use of the GSS_Wrap() call yields a token which encapsulates the
   input user data (optionally encrypted) along with associated
   integrity check quantities. For WRAP tokens, tokenType is set to 
   WRAP-Token and tokenContents is set to the following WrapToken :
   
   WrapToken ::= SEQUENCE {
     userData    [0] WrapData,

Lebastard, Pinkas                                           [ Page 10 ]
Internet-Draft                 Document Expiration : September 25, 1999

     seal        [1] OCTET STRING
   }
   
   WrapData ::= SEQUENCE {
     userText    [0] OCTET STRING,
     textMode    [1] ENUMERATED {
                        isClear     (1),
                        isEncrypted (2)
     },
     seqNumber   [2] INTEGER OPTIONAL
   }
   
5.3.2.1. Message Integrity Only

   If the conf_req input argument to GSS_Wrap is set to FALSE, GSS_Wrap
   yields a WrapToken encapsulating the input user data. The seal field
   is computed using the following formula :
   
      seal = OWF ( IDK, Data-Encoding, IDK )
      
   where Data-Encoding is the BER encoding of the WrapData item where
   userText is set to the input user data, textMode is set to isClear,
   textLen is set to the length of the input user data and seqNumber is
   set to the message sequence number if GSS_C_SEQUENCE_FLAG is active
   for the current context.
   
   The OWF used to compute the mic is the same as the OWF used during
   the secure context establishment.
   
   Upon reception of a WrapToken with textMode set to isClear, the peer
   BER-encodes the received WrapData item, computes a seal with the
   above formula and verifies that it matches the received seal.
   
5.3.2.2. Message Privacy

   If the conf_req input argument to GSS_Wrap is set to TRUE, GSS_Wrap
   yields a WrapToken encapsulating the encrypted user data. The seal
   field is computed using the following formula :
   
      seal = OWF ( CDK, Data-Encoding, IDK )

   where Data-Encoding is the BER encoding of the WrapData item where
   userText is set to the encrypted user data, textMode is set to
   isEncrypted, textLen is set to the length of the input user data and
   seqNumber is set to the message sequence number if
   GSS_C_SEQUENCE_FLAG is active for the current context.
   
   The OWF used to compute the seal is the same as the OWF used during
   the secure context establishment.

   The user data encryption algorithm is based on the use of the same
   OWF. The emitter BER-encodes the following UserMessage item :
   
   UserMessage ::= SEQUENCE {

Lebastard, Pinkas                                           [ Page 11 ]
Internet-Draft                 Document Expiration : September 25, 1999

        confounder      [0] OCTET STRING,
        originalText    [1] OCTET STRING
   }
   
   where confounder contains an 8 bytes random confounder and userText
   contains the user's provided text.
   
   If SHA1 is being used, then the BER-encoded UserMessage is divided
   into blocks of 20 bytes. If MD5 is being used, then the UserMessage
   is divided into blocks of 16 bytes.

   The first block B0 is encrypted to form an encrypted block C0. The 
   computation for this first block is performed by XORing B0 with 
   a OWF applied to the Confidentiality Dialogue Key as follows :

      C0 = B0 XOR OWF(CDK)

   Each subsequent block Bn is encrypted to form an encrypted block 
   Cn as follows :

      Cn = Bn XOR OWF(Cn-1, CDK)

   The last block is padded up to 20 or 16 bytes respectively using
   ones.

   Upon reception of a WrapToken with textMode set to isEncrypted, the
   peer first verifies the message seal using the integrity dialogue
   key. It then computes the set of encryption keys with the above
   formulas and applies the same encryption procedure. It finally
   BER-decodes the UserMessage item to get the original user text
   (ignoring the padding bytes and discarding the confounder).

5.4. Error Tokens

   GSS-API-Easy GSS-API mechanism supports error tokens in order to
   allow enhanced error checking.

   Any GSS-API routine emitting tokens (GSS_InitSecContext, 
   GSS_AcceptSecContext, GSS_Wrap, GSS_GetMIC, GSS_ExportSecContext,
   as well as the change passphrase procedure) may produce an error
   token.

   For Error Tokens, tokenType is set to ERR-Token and tokenContents
   is set to the following ErrToken :

   ErrToken ::= SEQUENCE {
     errData      [0] ErrorData,
     seal         [1] OCTET STRING
   }
   
   ErrorData ::= ENUMERATED {
                              GSS_E_FAILURE    (1),
                              GSS_E_DECODING   (2),
                              GSS_E_REPLAY     (3),

Lebastard, Pinkas                                           [ Page 12 ]
Internet-Draft                 Document Expiration : September 25, 1999

                              GSS_E_AUTH       (4),
                              GSS_E_ANON       (5),
                              GSS_E_VERIFY     (6),
                              GSS_E_DECRYPT    (7),
                              GSS_E_CLOCK_SKEW (8),
                              GSS_E_NEW_PWD    (9),
                              GSS_E_WRONG_PWD  (10),
                              GSS_E_PWD_POLICY (11)
   }

   where :

       GSS_E_FAILURE    identifies a (OS-related) system error

       GSS_E_DECODING   identifies a BER decoding error

       GSS_E_AUTH       identifies an authentication failure
       
       GSS_E_ANON       indicates that anonymous authentication is not
                        authorized by the acceptor

       GSS_E_REPLAY     identifies a context establishment replay error

       GSS_E_VERIFY     identifies an integrity error on the DataToken

       GSS_E_DECRYPT    identifies a decryption error on the DataToken

       GSS_E_CLOCK_SKEW indicates that the clock skew between the
                        peers' machines is too large to check context
                        establishment replay detection.

       GSS_E_NEW_PWD    indicates that the current passphrase has
                        expired and should be modified 

       GSS_E_WRONG_PWD  indicates that the current passphrase provided
                        for the change passphrase procedure is not the
                        current passphrase.

       GSS_E_PWD_POLICY indicates that the new passphrase provided for
                        the change passphrase procedure does not 
                        conform to the server policy.

   The seal of an ErrToken is computed according to the MIC rule on the
   BER-encoding of the ErrData data structure.

   If the GSS_E_NEW_PWD error status is received by a client, then the
   GSS-API routine call should return GSS_S_CREDENTIALS_EXPIRED to the
   invoker (or GSS_S_CONTEXT_EXPIRED if the request to change the
   passphrase occurs during a user message exchange).

6. Name Types

   This section discusses the name types which may be passed as input

Lebastard, Pinkas                                           [ Page 13 ]
Internet-Draft                 Document Expiration : September 25, 1999

   to the GSS-API-Easy GSS-API Mechanism GSS_Import_name() call, and
   their associated identifier values. In addition to specifying OID
   values for name type identifiers, symbolic names are included and
   recommenced to GSS-API implementors in the interest of convenience
   to callers.

   GSS-API-Easy supports a subset of name types defined in [GSSV2] :

     GSS_C_NT_EXPORT_NAME         { 1,3,6,1,5,6,4 }
     GSS_C_NT_ANONYMOUS           { 1,3,6,1,5,6,3 }
     GSS_C_NT_USER_NAME           { 1,2,840,113554,1,2,1,1 }
     GSS_C_NT_HOSTBASED_SERVICE   { 1,3,6,1,5,6,2 }

   Any of the above name types may be provided as input to the
   GSS-API-Easy Mechanism GSS_Import_name() call. The name value
   provided to GSS_Import_name() call shall consist of a non
   zero-length printable string.

   Note that for the GSS_C_NT_HOSTBASED_SERVICE name type (name of the
   form service@hostname), the "hostname" may be omitted but the "@"
   must always be present.

7. SECURITY CONSIDERATIONS

   The GSS-API-Easy authentication protocol is subject to dictionary
   attacks. Users should be required to choose passphrases with a
   minimum length of eight characters and be educated to choose their
   passphrases using more than the basic 26 letters from the alphabet.
   
   If they use upper and lower case characters including the 10
   digits and a few special characters, a passphrase complexity
   equivalent to 64 characters mixed on eight positions may be 
   achieved. This is equivalent to 2 to 6, raised at the power 8, 
   hence a key length equivalent to 48 bits. 

   In order to reduce the rate of exhaustive search attacks, an
   additional step is introduced which limits the rate to roughly 4
   trials per second on a workstation similar to the workstation used
   by the client. The rate reduction is obtained by applying n times a
   OWF to both the client identifier and the client passphrase.

   As an example, the performances the OWF SHA1 and MD5 on a Pentium II
   333 MHz running Windows 98 have been measured as follows:

      Applied    10000 SHA1 in      110 ms
      Applied   100000 SHA1 in     1040 ms
      Applied  1000000 SHA1 in     6920 ms

      Applied    10000  MD5 in      110 ms
      Applied   100000  MD5 in      940 ms
      Applied  1000000  MD5 in     5820 ms

   With these figures, on the same single workstation, a year of

Lebastard, Pinkas                                           [ Page 14 ]
Internet-Draft                 Document Expiration : September 25, 1999

   exhaustive search attacks would allow to find 3600 x 24 x 365 x 4 
   keys that is 126.144.000 keys or 7,5 x 2 to 24 keys, roughly equal
   to 2 to 27 keys. With 50 % chance, this would take 2 to 20 years,
   or 1 million years.

   Such dictionary attack would also only be valid against a single
   user.

   Replay detection is achieved by the target by storing in a table
   information about the most recent successful authentications.
   Storing both the received time and the confounder during a five
   minutes window time frame is sufficient since it is very unlikely
   that two different clients will pick up the same confounder at the
   same time.

   Replay detection is achieved by the client by verifying that the
   same time and confounder as sent by the client are used by the
   target.

   Replay protection on a different verifier is achieved through the
   use of the server name as part of the computation of the
   authentication data.

   The change passphrase protocol might be subject to replay attacks 
   if two change passphrase operations where sent during the same 
   session. The use of the current passphrase and its verification by 
   the target prevents the replay attack.

   The change passphrase protocol may be followed by a voluntary or 
   accidental connection break down. In some cases it may be 
   difficult to know whether the passphrase has or has not really be
   changed at the target. The client software should be prepared to
   handle this kind of situation and alert the user that he might 
   need to remember the old passphrase.

REFERENCES

   [GSSV2]    Internet Draft, John LINN, 16 December 1998
              "Generic Security Service Application Program Interface
              Version 2, Update 1"
              (draft-ietf-cat-rfc2078bis-08.txt)

   [GSSV2-C]  Internet Draft, John WRAY, November 1998
              "Generic Security Service API Version 2 : C bindings"
              (draft-ietf-cat-gssv2-cbind-08.txt)

AUTHORS' ADDRESSES

Jacques Lebastard
BULL S.A.
Rue Jean Jaures

Lebastard, Pinkas                                           [ Page 15 ]
Internet-Draft                 Document Expiration : September 25, 1999

F-78340 LES CLAYES SOUS BOIS

Phone : +33 1 30 80 77 86
Fax   : +33 1 30 80 77 99
Email : [email-masked]

Denis Pinkas
BULL S.A.
Rue Jean Jaures
F-78340 LES CLAYES SOUS BOIS

Phone : +33 1 30 80 34 87
Fax   : +33 1 30 80 33 21
Email : [email-masked]

Lebastard, Pinkas                                           [ Page 16 ]

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Tue, 2 Mar 1999 18:00:47 -0500 (EST)

Denis, 

	Thanks for taking the time to write a GSS-APi-Easy mechanism.  I
think it is very much in the right direction of what we need for folks
who desire a low-infrastructure GSSAPI mechanism.  I have only a few
comments.

	I note that the encryption algorithm is not specified in the
current draft.  Obviously this will need to be rectified in the long
run.  This brings up the interesting question of which crypto algorithm
to use.  The problem is that right now, there isn't any universally
liked choices.  DES is too weak, triple-DES is too slow.  A number of
other liked algorithms have Intellectual Property entaglements of one
kind or another.  (RC4, IDEA, etc.)  When the AES process finishes in a
year or so, I'm sure we'll be in a better position.  Until then, though,
what do we do?  (I know, use the newly released Skipjack algorithm!  :-)

	So, how do we handle this?  I suspect we will end up needing to
simply pick one mandatory-to-implement algorithm one way or the other.
I'd also suggest including a list of algorithms supported by the
initiator in the InitReqToken, and making sure that list is included in
the AuthProofData to avoid an enemy from spoofing the list.  (In the case
of one-way authentication, the server would have to send a token back to
the client to complete the negotiation so the client knew what kind of
encryption algorithm it should use when sending data which is to have
confidentiality protection.)

	For the sake of simplicity, though, it's not clear to me whether
it is useful to specify a MD5 checksum variant, given that SHA is
generally accepted as being better.   I would simply make SHA mandatory
to implement, and possibly omit MD5 altogether.

							- Ted
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 03 Mar 1999 08:52:34 +0100

> current draft.

In fact it is. Take a closer look at page 12. The idea is to use one way
functions for everything. This was to close the debate whethe, e.g. DES or
T-DES should be used. Of course this has some drawbacks. This is surely not as
fast as DES or T-DES  but do not forget that this is an entry level and that
people should still find some advantages to move to more powerful GSS
mechanisms. When looking at the figures obtained on a PC for hashing this is
however not so slow as we might expect.

Anyway the strength of the data encryption is only as good as the lowest of
the strength of the algorithm and the appropriate choice of the passphrase
from which the encryption key is derived.

> Obviously this will need to be rectified in the long

At the moment a single encryption mode is specified with two variants based on
SHA-1 and MD5.

> to implement, and possibly omit MD5 altogether.

I have no strong opinion on this topic and would have no problem to mandate
SHA-1 for the time being. However we should keep provisions for other
algorithms in case SHA-1 gets deprecated in the future because of  some new
discovery from a genius.

In this way, we get a single unpatented (as far as I know) encryption
algorithm. :-)

Denis

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 3 Mar 1999 14:34:59 -0500 (EST)

Date: Wed, 03 Mar 1999 08:52:34 +0100
   From: Denis Pinkas <[email-masked]>

   In fact it is. Take a closer look at page 12. The idea is to use one
   way functions for everything. This was to close the debate whethe,
   e.g. DES or T-DES should be used. 

Sorry, I stand corrected.  I somehow missed this the firist time around
when I read your document.  One downside of using a OWF as a encryption
algorithm is its speed; the other is that its cryptographic properties
are not as well understood.  I think we'd want to have a cryptographer
look over your proposal and comment on whether they think it's strong.
I think I've found one obvious problem with it, just after looking at it
very briefly:

Since the first block uses an XOR of a constant value, CDK:

      C0 = B0 XOR OWF(CDK)

... this means that given known plaintext (suppose the first WRAP'ed
token contains a constant version string), an attacker can XOR away the
plaintext, and reveal OWF(CDK).  For subsequent wrapped tokens, the attacker
will be able to see the first block of since OWF(CDK) remains constant.

I see there's an attempt to put an 8-byte confounder in the UserMessage
which gets encrypted, but that doesn't help protect the first block.
All this means is that roughly 8 bytes of user data will be exposed by
this attack, since the attacker can simply ignore the confounder, XOR
away the first 8 bytes of known plaintext to reveal the last 8 bytes
of OWF(CDK), which can then be used to read the first 8 bytes of all
subsequent wrap'ed tokens.  (This is assuming that we're using SHA which
uses a 20-byte hash, and that the BER encoding overhead plus the
confounder eats up roughly 12 bytes.)

The fix for this particular problem is obvious; remove the confounder,
and add instead an 8-byte initial vector:

    C0 = B0 XOR (IV, CDK)

and include the random IV in the Wrap token.

There may be other problems with this scheme, though; I'm not a
cryptographer, and this was just the most obvious issue that I found
with it.  We'd definitely want to presume on someone with more
cryptographic analysis credentials than I to look over the use of the
OWF as an encryption algorithm, just to make sure there isn't something
which those of us lay folks might have overlooked.  :-)

							- Ted

---

From: David Jablon <[email-masked]>
Date: Wed, 03 Mar 1999 19:43:08 -0500

Denis,

The Security Considerations section of draft-ietf-cat-gsseasy-00
focuses on a calculation for the difficulty of dictionary attack.
I believe this section as written leads the reader to a false
sense of security.

For a *randomly generated* password ("Jd9&eIm1"), the numbers
might work, though for completeness you should mention
threats of faster machines and parallel attack.

But for a user-chosen password ("Qwertyui"), the threat
is severely understated.  People are notoriously bad random
generators.  Furthermore, there's no reliable way to measure
randomness in a given choice.

It seems like pure speculation to quantify the difficulty
of cracking *chosen* passwords, phrases, or paragraphs.
To attempt this properly, one must take into account
studies of human behavior.

The documentation problem can be addressed by a clearer
statement of assumptions.  If it doesn't mandate using a
generated 48-bit (or larger) random password, it may be
best to suggest what is likely to happen, given what we
do know about human behavior.

(Of course, one could also argue that time is better spent
 addressing the technical problem.  :-)

-------------------------
David P. Jablon
[email-masked]
+1 508 898 9024
www.IntegritySciences.com

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 04 Mar 1999 09:05:48 +0100

David,

I agree with all what you say. If you want to propose a re-phrasing of the
security considerations section, I would be more than happy.

Regards,

Denis

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 4 Mar 1999 14:32:45 -0500 (EST)

Date: Thu, 04 Mar 1999 09:05:48 +0100
   From: Denis Pinkas <[email-masked]>

One of the ways we can mitigate the problem here is to note that the
server gets a copy of the plaintext password, and the server can do a
password quality check.  Since it does have access to the raw plaintext
password, it can be much more efficient than a brute-force password
cracker at making sure that the user has chosen a high-quality password
which is not as succeptible to brute force attackers.

What we would need to add to the draft is a method by which the server
can reject a password change because the new password did not meet some
standard of password quality.

As far as Thomas Wu's paper is concerned, I haven't had a chance to read
it (if someone can send me via private e-mail a pointer to the URL of
his NDSS paper, I would be much obliged).  However, I will note that he
controls the SRP patent, and thus has a financial motivation towards the
conclusion which he apparently reached.  Another way of solving this
problem, though, which does not have any patent encumberances, is to
simply not allow users to chose low-quality passwords in the first
place.  (And of course Denis's technique of using a slower-speed string
to key algorithm is also a good way to make brute force attacks less
tractable.)

						- Ted

---

From: David Jablon <[email-masked]>
Date: Thu, 04 Mar 1999 17:40:34 -0500

> security considerations section, I would be more than happy.

I'll draft something simple based on the mailing list comments.
Referring to other papers, such as Mary Zurko's suggestion of
Wu's, would be useful, but its best to consolidate and
summarize these issues.

At 02:32 PM 3/4/99 -0500, Theodore Y. Ts'o wrote:
> password, it can be much more efficient [...]
>

Good points.  But password filtering is still just a remedial step.
It's not the best solution to remove network vulnerability.
One should never underestimate the power of people to choose
bad passwords.  People will keep picking passwords using
whatever method they think of until the built-in filter
finally approves.  This says nothing about whether the choice might
be in a slightly larger or smarter dictionary.

> conclusion which he apparently reached. [...]

Ted, I think you do an extreme disservice to Dr. Wu in
presuming a bias, especially since you haven't read the paper.
Like anyone, he has a personal interest and pride in his work.
But you're wrong about the patent.  Stanford University
controls the patent, and their "trickle down" track record
of reimbursing inventors guarantees that Tom will continue
to work for a living.  (Just ask Whit where the millions are.)
But, back to technical issues ...

>  [...] Another way of solving this

It's been tried, unsuccessfully, many times.  The way to
"simply" prevent low quality choices is to mandate the use of a
random generation method to get a password of sufficient size
and complexity.  I already suggested this as an unpatented
solution.  But unless generated passwords are a MUST,
EKE-style methods always provide more protection for safe
network verification.

Filtering offers nothing even close to a guarantee.
But it does have value:  In conjunction with a slow hash,
it is merely an acceptable practice for minimizing the
vulnerability of a *database* of hashed passwords of
indeterminate quality.

-- David

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 4 Mar 1999 19:06:04 -0500 (EST)

Date: Thu, 04 Mar 1999 17:40:34 -0500
   From: David Jablon <[email-masked]>

No, but I've seen previous postings/web pages by Dr. Wu on the subject.

Now that I've read the paper, I see that it can be summed up in one
sentence.  "I used a sufficiently better password cracking dictionary
than the one used by the Kerberos realm's password quality checker, so I
was able to crack 8% of the passwords used by users in that realm."

   to work for a living.

Hmm, well then obviously MIT's Technology Licensing Office offers a much
better deal (33% to the inventor, 33% to his/her department, 33% to
MIT), but I disgress.....

   It's been tried, unsuccessfully, many times.  

Well, the realm which Wu attacked had password quality checking, and
that held his success rate down to 8%.  I'm not really sure that should
be considered "unsuccessful".  To me it is an open question whether or
not with a greater effort that percentage rate could be pushed down even
further.  

Remember that in any authentication system there will always be failures
of varying different kinds, including users giving their passwords to
their SO's/wives/secretaries, users reusing their password for insecure
services on the web, etc. --- none of which we can completely eliminate.
So in that context, clueless users chosing bad passwords is only one of
the potential failure modes, and so a non-zero failure rate isn't
necessarily a disaster, if we can push it down to a tolerable degree.

And of course, being engineers we need to trade off the difficulty of
engineering a solution which can push that 8% even further down, versus
the cost of dealing with a patent holder.  Forcing users to use randomly
generated passwords is one, using a better password quality checker is
another.  All three potential solutions (mechanically chosen passwords,
better password quality checking, and dealing with a patentholder) have
tradeoffs, and the essence of engineering is chosing between those
tradeoffs.

Given past history of how patents can distort the standards process, and
delay or even prevent implementations, the IETF tries to avoid the use
of patented technology whereever possible, unless the patented
technology lends a clear and convincing advantage.  My own personal view
is that in this case the advantage lent by SRP, SPEKE, EKE, and the rest
are marginal for meeting that standard.  But that's only a personal
view...

						- Ted

---

From: Jonathan Trostle <[email-masked]>
Date: Thu, 04 Mar 1999 20:06:07 -0800

The realm that Wu attacked didn't have much of a password policy since he
found some passwords with 1 and 2 characters. Password expiration has to be
part of any reasonable password policy to prevent the old weak passwords
from living on indefinitely.

It would be interesting to see his attacks repeated against a realm with a
more substantial password policy. As with any security policy, it should be
possible to articulate what the password policy is.

Jonathan

---

From: Ken Hornstein <[email-masked]>
Date: Fri, 05 Mar 1999 00:04:57 -0500

>from living on indefinitely.

As an aside, I have code in my CVS tree (from Von Welch at NCSA)
that lets you run a Crack dictionary on new passwords in the V5
database.  With this in place, it should push down that rate a lot.

Also, IIRC his attack was using V4.  Might be tougher using V5
(possibly more decryptions, string2key() requires the principal
name as the salt, etc etc).

--Ken

---

From: David Jablon <[email-masked]>
Date: Fri, 05 Mar 1999 11:51:15 -0500

These comments on cracking GSS-Easy, and similar methods, seem to
be at the heart of the motivation for low-infrastructure GSS ...

At 07:06 PM 3/4/99 -0500, Theodore Y. Ts'o wrote:
> Now that I've read [Wu's] paper, I see that it can be summed up in one

I think 8% cracked, or even 1% cracked, sounds like a serious
indictment to me.  I wouldn't want to defend a system that
practically guaranteed a significant failure rate against
network attack, especially when it's completely preventable.

Furthermore, it seems obvious that the failure rate is more
likely to be greater, in realms with less control, against
bigger or smarter attacks, or maybe with just a "normal" population
of users, rather than Stanford and MIT students, who
might be unusually responsive to password education.

> services on the web, etc. --- none of which we can completely eliminate. 

Password reuse and disclosure are much easier issues
for people to handle than password choice.  Selecting
and memorizing a cryptographically large password
is intractible, or undesirable, for many people.

> necessarily a disaster, if we can push it down to a tolerable degree.

A zero-failure rate seems vastly preferable to me.

Lumping these problems together and dismissing them as
as a group does not help to increase security.
In fact, one could argue the contrary, that solving the
"choice" problem helps to reduce these other problems.

Choosing a "formerly-known-as-bad" password is *not* a
failure mode when using SPEKE et. al. in combination with
other basic security practices.  I see it as a fundamental issue of
using technology to best address what we know about human
behaviour.  And labeling users as "clueless" doesn't help.

> are marginal for meeting that standard.  But that's only a personal

This seems to be the real issue for you, and others, whereas
the "no authentication is perfect" argument sounds like
mere rationalization.

In private conversations with several people I'm discussing some
ideas, from free open source licensing, to free use of SPEKE
in restricted forms.  Unlike many technology developers,
I'm in a position to actually do something to remove the
patent barrier.

I encourage others to respond, who might appreciate these
benefits, but are reluctant to endorse stronger
"low-infrastructure" methods for whatever reason.
Private (even anonymous) comments are welcome, and may
be preferred to avoid clutter on the list.

-- David

---

From: Chris Newman <[email-masked]>
Date: Fri, 05 Mar 1999 16:14:44 -0800 (PST)

A few observations:

* The last thing we need is yet another string-to-key function on the
standards track.  I'd encourage either the RFC 2069 string-to-key:
    MD5( username ":" realm ":" passphrase )
or the Kerberos-V5 string-to-key.  While I suspect neither of these is
perfect, if you factor in the cost of a string-to-key migration at a site,
either of these is far better than anything new.

* If you're doing a new mechanism, I don't see why you don't take more
advantage of HMAC.  HMAC is really easy to implement and seems like a
better way to combine "secret" and "public" information using a OWF.

* Ted suggested using SHA-1 only.  If you exclude the string-to-key issue,
I like the idea given that reducing options is almost always a good thing. 
But if you take that path, somebody needs to publish the equivalent of RFC
1321 for SHA-1, otherwise it would make the mechanism harder to deploy.

* The fact that the draft doesn't describe how to convert the data
structures to the "bytes-on-the-wire" necessary to make it work means I'd
never consider wasting time implementing it unless it got widely deployed
by people I had to interoperate with first (I wouldn't be surprised if
many other apps people felt the same).  The easiest way to fix this
problem would be to get rid of all the ASN.1 and use something simple like
XDR (RFC 1832) instead.

		- Chris

---

From: "Howard Chu" <[email-masked]>
Date: Fri, 5 Mar 1999 22:15:04 -0800

> either of these is far better than anything new.

Just for the sake of easy migration, I'd like to suggest that one form of
"passphrase" to consider above should be the Unix crypt'd password, instead
of a plaintext string. It may not be great, but it's ubiquitous, and allows
newly installed sites to painlessly transition to a better mechanism,
without requiring the server to know users' plaintext passwords. The actual
exchange
will need a couple of extra steps:

     Client->   username
     Server->   salt

     Client...  MD5( username ":" realm ":" crypt'd password )

Following a successful authentication, the server can return a Password
Expired result code and force the user to choose a new password, which will
get the user enrolled into the new password database...

(Yes, obviously not all the world's a Unix box, but there's enough of 'em,
and requiring knowledge of a user's existing plaintext password is just
going to make smooth transitions impossible. Besides, systems that *do* have
access to users' plaintext passwords can still use crypt...)
  -- Howard

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 08 Mar 1999 10:10:30 +0100

Ted,

It took me a little bit longer to answer to this mail.

I have some difficulties to understand how your scheme may work. How should the
IV be transmitted ? I would rather propose the following alternative :

1) extend the confounder to 20 bytes.
2) forget about the ASN.1 encoding of the message to be encrypted. In this way
there would be no leakage at all, even on the TL (V) encoding of the confounder.

This basically means that the data to be encoded would be composed of 20 random
bytes concatenated with the message to be encrypted and where the last byte (or
word ?) of that encrypted data would indicate the exact size of the original
clear message.

I agree with you that encryption techniques using one way functions have not
been much studied. However, this does not mean that there are necessarily
insecure. It might be a good topic to consider for Crypto 99 or Crypto 2000. :-)

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 08 Mar 1999 10:56:24 +0100

Howard,

My comments are along the lines.

>      Client...  MD5( username ":" realm ":" crypt'd password )

Doing that would have a major drawback. The actual mechanism allows unilateral
authentication to be done in just one exchange. I believe it is essential to
maintain this property.

Denis

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Mon, 8 Mar 1999 11:16:01 -0500 (EST)

Date: Mon, 08 Mar 1999 10:10:30 +0100
   From: Denis Pinkas <[email-masked]>

   I have some difficulties to understand how your scheme may work. How
   should the IV be transmitted ? 

Sorry, I wasn't explicit in my proposal; the assumption was that (as is
required by all IV schemes) the IV would be included before the body of
the encrypted information; for example, after the Message Integrity Code
field.

   I would rather propose the following alternative :

   1) extend the confounder to 20 bytes.  
   2) forget about the ASN.1 encoding of the message to be encrypted. In
   this way there would be no leakage at all, even on the TL (V)
   encoding of the confounder.

I'd need to think about this a bit more before I'd be comfortable with
this.  Better yet, it would be nice if we could get a quick opinion from
someone like Uri or Hugo that it at least isn't obviously insecure (to a
cryptographer).

   I agree with you that encryption techniques using one way functions
   have not been much studied. However, this does not mean that there
   are necessarily insecure. It might be a good topic to consider for
   Crypto 99 or Crypto 2000. :-)

Well, widespread deployment of such a scheme is a great way of
guaranteeing that it will get more attention at Crypto 99 or Crypto
2000.  Just so long as it isn't a case of a crypto system getting
presented at the conference, and it break getting presented next day
during the rump session!  :-)

						- Ted

---

From: Chris Newman <[email-masked]>
Date: Tue, 09 Mar 1999 13:24:53 -0800 (PST)

>      Client...  MD5( username ":" realm ":" crypt'd password )

Two other problems with this idea that haven't been mentioned:

(1) Like it or not, Unix crypted passwords are often treated as "safe" for
public consumption (via things like NIS and traditional /etc/passwd).  If
knowing the crypted password is sufficient to authenticate, you've created
a major operational weakness.

(2) If the lightweight mechanism can be done such that clients only need
MD5() for authentication, it is much easier to deploy (CRAM-MD5, for
example, is getting deployed very quickly in email app protocols).  Unix
crypted passwords require the DES-based crypt() function which is a lot of
additional complexity.

		- Chris

---

From: "Howard Chu" <[email-masked]>
Date: Tue, 9 Mar 1999 14:18:59 -0800

> a major operational weakness.

Good point. I've been using a similar scheme in-house for some time, but all
of our target systems use shadow password files and we certainly don't use
NIS. As for crypted passwords being safe for public consumption - anyone
who's seen the Crack distribution knows this is untrue. My feeling is that
if you're already being that careless about security, you probably aren't
interested in really secure authentication... From a different perspective,
if you are using NIS or you don't use shadow passwords, the issue is
irrelevant because anyone who wanted to break into your system probably
already has. But if this is the position you're in, then you're right, and
an automated migration mechanism like what I propose is inappropriate;
you'll need to migrate accounts manually and preferably with face-to-face
contact.
> crypted passwords require the DES-based crypt() function which is a lot of
I'm not so sure about this one, crypt() source code is freely available from
a number of places. We've deployed the client side of our authentication
scheme on the lowliest Macs and PCs without any problem.