INTERNET-DRAFT                                             J. Lebastard
IETF Common Authentication Technology WG                      D. Pinkas
<draft-ietf-cat-gsseasy-01.txt>                               Bull S.A.
                                                       October 20, 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 RFC 2026.

   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 "cat-ietf@mit.edu", 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 SharedSecret shared between
   the client and the server and uses a protocol where the passphrase
   (i.e. a long phrase used like a password) is never sent in the clear.
   In addition, this document describes a protocol to change the
   SharedSecret.

   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 :    April 20, 1999

GENERAL

   The first section of this Internet-Draft specifies the GSS-API-Easy
   authentication protocol. Section 2 describes the change SharedSecret
   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.


. The authentication protocol

   The GSS-API-Easy mechanism is based on the use of a single one-way
   cryptographic function. It does not use any authentication server.
   The term "PassPhrase" identifies a secret known only to the client
   which contains more characters than usual passwords (sometimes
   limited to eight characters) in order to lengthen password
   dictionary attacks.

   The method requires that both peers (the client, acting as the
   initiator, and the server, acting as the acceptor) share a secret
   called "SharedSecret". The SharedSecret is built using the
   following formula:

        SharedSecret = OWF (ClientName, PassPhrase, ServerName)

      where OWF is a One Way collision resistant Hash function

   It should be noticed that the SharedSecret is different for every
   server and that every server ignores the value of the PassPhrase.
   Thus a server cannot masquerade and use its known SharedSecret to
   log on another server that is using the same PassPhrase.

   In order to make dictionary attacks difficult, the authentication
   data that is sent along the communication line, is computed using
   a value, called "Passkey", that is built using a one-way function
   many times (e.g. ten thousands).

   The Passkey is locally derived using a one-way function applied
   N times to the SharedSecret.

      PassKey = (OWF)N (SharedSecret)

   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.



Lebastard, Pinkas                                            [ Page 2 ]


Internet-Draft                  Document Expiration :    April 20, 1999

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.

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

      AuthProof = OWF (PassKey, Time-C, Confounder-C, 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 SharedSecret. It then
   uses the received Confounder and Time to compute an AuthVerif :

      AuthVerif = OWF (PassKey, Time-C, Confounder-C, 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.

Lebastard, Pinkas                                            [ Page 3 ]


Internet-Draft                  Document Expiration :    April 20, 1999

   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,
                         PassKey)

   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,
                      PassKey)

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

. Change SharedSecret Mechanism

   When a user wishes to change the SharedSecret he shares with a peer,
   he simply needs to send a change SharedSecret token that contains
   both the current and the new SharedSecret encrypted with a key
   derived from the current PassKey. This change SharedSecret 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 SharedSecret using the current confidentiality
   dialogue key.

   The change operation will be accepted by the target only if two
   conditions occur : the seal is correct, the current SharedSecret sent
   by the client matches the current SharedSecret known to the target.

   If the change is accepted by the target then the change SharedSecret
   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 change SharedSecret
   token otherwise MIC and WRAP tokens will be rejected.

Lebastard, Pinkas                                            [ Page 4 ]


Internet-Draft                  Document Expiration :    April 20, 1999


. Security Services

   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.

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





Lebastard, Pinkas                                            [ Page 5 ]


Internet-Draft                  Document Expiration :    April 20, 1999

. 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

   [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 SharedSecret, 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),
                          CHANGE-Req-Token   (2),
                          CHANGE-Resp-Token  (3),
                          MIC-Token          (4),
                          WRAP-Token         (5),
                          ERR-Token          (6)
     },



Lebastard, Pinkas                                            [ Page 6 ]


Internet-Draft                  Document Expiration :    April 20, 1999


     tokenContents  [1] CHOICE {
       initReqToken     [0] InitReqToken,
       initRespToken    [1] InitRespToken,
       passReqToken     [2] PassReqToken,
       passRespToken    [3] PassRespToken,
       micToken         [4] MicToken,
       wrapToken        [5] WrapToken,
       errToken         [6] ErrToken
     }
   }

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,
     passKey           [3] OCTET STRING
   }

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


Lebastard, Pinkas                                            [ Page 7 ]


Internet-Draft                  Document Expiration :    April 20, 1999


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

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

   The ServerName item used in the computation of PassKey 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,

Lebastard, Pinkas                                            [ Page 8 ]


Internet-Draft                  Document Expiration :    April 20, 1999

     confounderC       [3] OCTET STRING,
     passKey           [4] OCTET STRING
   }

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

5.2. Change SharedSecret Tokens

   The change SharedSecret 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 SharedSecret Request

   The change SharedSecret token contains the above GssApiEasyToken
   structure with tokenType set to CHANGE-Req-Token and tokenContents
   set to the PassReqToken data structure defined as :

   PassReqToken ::= SEQUENCE {
     sharedSecretData      [0] OCTET STRING,
     seal                  [1] OCTET STRING
   }

   where sharedSecretData contains the encrypted BER-encoding of the
   following data structure :

   SharedSecretData ::= SEQUENCE {
     confounder            [0] OCTET STRING,
     currentSharedSecret   [1] OCTET STRING,
     newSharedSecret       [2] OCTET STRING
   }

   where confounder contains a random 8 bytes array.

   The encryption rule used during the change SharedSecret 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 SharedSecretData item using
   the rule described for integrity WRAP token in section 5.3.2.1. of
   this document.

5.2.2. Change SharedSecret Response

   Upon reception of a change SharedSecret request, the server verifies
   the seal of the SharedSecretToken and decrypts the SharedSecretData.
   Then a new passphrase acceptance token is returned to the emitter.
   This token consists in an GssApiEasyToken with tokenType set to
   CHANGE-Resp-Token and tokenContents contains the ChangeRespToken data
   item defined as :

Lebastard, Pinkas                                            [ Page 9 ]


Internet-Draft                  Document Expiration :    April 20, 1999

     ChangeRespToken ::= OCTET STRING

   That token contains the MIC of the above ChangeReqToken. 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
   change SharedSecret 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.




Lebastard, Pinkas                                           [ Page 10 ]


Internet-Draft                  Document Expiration :    April 20, 1999

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


Lebastard, Pinkas                                           [ Page 11 ]


Internet-Draft                  Document Expiration :    April 20, 1999

   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 prepares the following UserMessage item which is
   composed of a confounder (random number) followed and concatenated
   with the original text to be encrypted.

   If L is the size in bytes of the output of the hash function being
   used by the security mechanism, then the confounder contains L bytes
   that are placed in front of the original text to be encrypted,
   followed by that original text that is divided into blocks of
   L 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 may contain exactly L bytes or less.

   If it contains exactly L bytes, then an additional block of L bytes
   is added, where the last byte contains the number of bytes from the
   last block to be discarded by the receiver (in that case L) and the
   other bytes contain ones.

   If it contains less than L bytes, then the last byte contains the
   number of bytes from the last block to be discarded by the receiver
   (in that case a value between 1 and L-1) and the bytes between the
   last byte of the original text and that last byte are filled in with
   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
   obtains the confounder followed by the original text padded to
   a multiple of L bytes. It discards the confounder and truncates the
   original text to its original size using the padding information
   present in the last byte.

5.4. Error Tokens

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

Lebastard, Pinkas                                           [ Page 12 ]


Internet-Draft                  Document Expiration :    April 20, 1999

   Any GSS-API routine emitting tokens (GSS_InitSecContext,
   GSS_AcceptSecContext, GSS_Wrap, GSS_GetMIC, GSS_ExportSecContext,
   as well as the change SharedSecret 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),
                              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 SharedSecret has
                        expired and should be modified

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

Lebastard, Pinkas                                           [ Page 13 ]


Internet-Draft                  Document Expiration :    April 20, 1999

   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
   SharedSecret occurs during a user message exchange).

. Name Types

   This section discusses the name types which may be passed as input
   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.

. 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 the secret shared between the client and the server.




Lebastard, Pinkas                                           [ Page 14 ]


Internet-Draft                  Document Expiration :    April 20, 1999

   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
   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 SharedSecret protocol might be subject to replay attacks
   if two change SharedSecret operations where sent during the same
   session. The use of the current SharedSecret and its verification by
   the target prevents the replay attack.

   The change SharedSecret protocol may be followed by a voluntary or
   accidental connection break down. In some cases it may be
   difficult to know whether the SharedSecret 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)

Lebastard, Pinkas                                           [ Page 15 ]


Internet-Draft                  Document Expiration :    April 20, 1999

   [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
F-78340 LES CLAYES SOUS BOIS
Phone : +33 1 30 80 77 86
Fax   : +33 1 30 80 77 99
Email : Jacques.Lebastard@bull.net


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 : Denis.Pinkas@bull.net






























Lebastard, Pinkas                                           [ Page 16 ]