One document matched: draft-ietf-cat-gsseasy-00.txt
INTERNET-DRAFT J. Lebastard
IETF Common Authentication Technology WG D. Pinkas
<draft-ietf-cat-gsseasy-00.txt> 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 "<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 : 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 ]
| PAFTECH AB 2003-2026 | 2026-04-23 11:42:52 |