INTERNET-DRAFT J. Lebastard IETF Common Authentication Technology WG D. Pinkas Bull S.A. June 22, 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 "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 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 : December 22, 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 : December 22, 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 : December 22, 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 : December 22, 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 "" 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 : December 22, 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 : December 22, 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 : December 22, 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 : December 22, 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 : December 22, 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 : December 22, 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 prepares the following UserMessage item which is composed of a confounder (random number) followed and concatenated with the original text to be encrypted. Lebastard, Pinkas [ Page 11 ] Internet-Draft Document Expiration : December 22, 1999 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. 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 } Lebastard, Pinkas [ Page 12 ] Internet-Draft Document Expiration : December 22, 1999 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 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). Lebastard, Pinkas [ Page 13 ] Internet-Draft Document Expiration : December 22, 1999 6. 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. 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 Lebastard, Pinkas [ Page 14 ] Internet-Draft Document Expiration : December 22, 1999 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 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 F-78340 LES CLAYES SOUS BOIS Lebastard, Pinkas [ Page 15 ] Internet-Draft Document Expiration : December 22, 1999 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 ]