idnits 2.17.1 draft-ietf-cat-gsseasy-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 956 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([GSSV2-C], [GSSV2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 359: '... } OPTIONAL,...' RFC 2119 keyword, line 360: '... owfIterations [6] INTEGER OPTIONAL,...' RFC 2119 keyword, line 514: '... seqNumber [0] INTEGER OPTIONAL,...' RFC 2119 keyword, line 525: '... seqNumber [0] INTEGER OPTIONAL,...' RFC 2119 keyword, line 560: '... seqNumber [2] INTEGER OPTIONAL...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 20, 1999) is 8952 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'APPLICATION 0' is mentioned on line 292, but not defined -- Looks like a reference, but probably isn't: '0' on line 662 -- Looks like a reference, but probably isn't: '1' on line 663 -- Looks like a reference, but probably isn't: '2' on line 560 -- Looks like a reference, but probably isn't: '3' on line 433 -- Looks like a reference, but probably isn't: '4' on line 434 -- Looks like a reference, but probably isn't: '5' on line 356 -- Looks like a reference, but probably isn't: '6' on line 360 -- Looks like a reference, but probably isn't: '7' on line 361 == Outdated reference: A later version (-09) exists of draft-ietf-cat-gssv2-cbind-08 Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. Lebastard 2 IETF Common Authentication Technology WG D. Pinkas 3 Bull S.A. 4 October 20, 1999 6 The GSS-API-Easy Mechanism 8 STATUS OF THIS MEMO 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Comments on this document should be sent to "cat-ietf@mit.edu", the 30 IETF Common Authentication Technology WG discussion list. 32 ABSTRACT 34 This document provides a description of a GSS-API mechanism usable 35 through the Generic Security Service Application Program Interface 36 (as specified in Internet-Drafts [GSSV2] and [GSSV2-C]) that is 37 easy to deploy since it does not rely on the existence of a 38 security infrastructure nor the existence of a security server. 40 The GSS-API-Easy mechanism enables unilateral and mutual 41 authentication of peers as well as per-message protections. It is 42 based on the use of an identifier and a SharedSecret shared between 43 the client and the server and uses a protocol where the passphrase 44 (i.e. a long phrase used like a password) is never sent in the clear. 45 In addition, this document describes a protocol to change the 46 SharedSecret. 48 This mechanism will help application programmers to develop 49 applications making use of GSS-API tokens and can be seen as a 50 first step before adopting techniques making use of security 51 infrastructures or security servers. 53 Lebastard, Pinkas [ Page 1 ] 54 GENERAL 56 The first section of this Internet-Draft specifies the GSS-API-Easy 57 authentication protocol. Section 2 describes the change SharedSecret 58 protocol. Section 3 gives the list of supported security services. 59 Section 4 specifies how session keys are established. Section 5 60 defines the GSS-API Token framing for this Mechanism. Section 6 61 discusses naming issues. Section 7 lists some security 62 considerations. 64 1. The authentication protocol 66 The GSS-API-Easy mechanism is based on the use of a single one-way 67 cryptographic function. It does not use any authentication server. 68 The term "PassPhrase" identifies a secret known only to the client 69 which contains more characters than usual passwords (sometimes 70 limited to eight characters) in order to lengthen password 71 dictionary attacks. 73 The method requires that both peers (the client, acting as the 74 initiator, and the server, acting as the acceptor) share a secret 75 called "SharedSecret". The SharedSecret is built using the 76 following formula: 78 SharedSecret = OWF (ClientName, PassPhrase, ServerName) 80 where OWF is a One Way collision resistant Hash function 82 It should be noticed that the SharedSecret is different for every 83 server and that every server ignores the value of the PassPhrase. 84 Thus a server cannot masquerade and use its known SharedSecret to 85 log on another server that is using the same PassPhrase. 87 In order to make dictionary attacks difficult, the authentication 88 data that is sent along the communication line, is computed using 89 a value, called "Passkey", that is built using a one-way function 90 many times (e.g. ten thousands). 92 The Passkey is locally derived using a one-way function applied 93 N times to the SharedSecret. 95 PassKey = (OWF)N (SharedSecret) 97 The number of iterations should be chosen by the client so that 98 it takes about 1/4 second on the client workstation to generate it. 99 In practice, for a workstation, figures between 10.000 and 100.000 100 iterations should be chosen. 102 This means that the number of attacks per second is greatly reduced. 103 Since the client identifier is part of the computation, dictionary 104 attacks have to be targeted towards a given user. 106 Lebastard, Pinkas [ Page 2 ] 107 1.1. Authentication Mechanism 109 The Authentication mechanism uses unique numbers composed of a time 110 and a random number. It is based on the use of loosely synchronized 111 clocks and has the advantage of allowing to perform a client 112 authentication in one exchange while being resistant to replay 113 attacks. 115 1.1.1. Unilateral Authentication 117 The client first picks up the local time and generates a random 118 number which is used as a confounder. 120 Then, an AuthProof is computed applying the one-way function to the 121 concatenation of the computed PassKey, the current local time, the 122 Confounder,and the PassKey : 124 AuthProof = OWF (PassKey, Time-C, Confounder-C, PassKey) 126 The GSS-API Context establishment token defined in section 5 of this 127 document includes the Confounder, the local time, the number of 128 iterations N of the OWF, the OWF algorithm identifier, both peers 129 names and AuthProof items. 131 If no error occurs while building that token, GSS_InitSecContext 132 returns GSS_S_COMPLETE to the invoker. 134 Upon reception of the GSS-API context establishment token, the 135 server combines the Confounder and Time item in a "UniqueNumber". 136 The server uses this UniqueNumber to perform a context establishment 137 replay detection. 139 If that replay check fails (i.e. if that UniqueNumber was not 140 previously received), the server obtains OWF and N from the context 141 token. It computes the PassKey using the proper SharedSecret. It then 142 uses the received Confounder and Time to compute an AuthVerif : 144 AuthVerif = OWF (PassKey, Time-C, Confounder-C, PassKey) 146 The authentication of the client succeeds if AuthVerif is the same 147 as the received AuthProof. 149 1.1.2. Mutual Authentication 151 Mutual authentication process requires an additional step. At the 152 the client side, the mutual authentication process differs in two 153 ways : 154 a) the Context establishment token includes the Mutual 155 Authentication flag, and 156 b) the GSS_InitSecContext() routine returns 157 GSS_S_CONTINUE_NEEDED to the invoker. 159 At the server side, the acceptor authenticates himself to the client 160 using a similar process. 162 Lebastard, Pinkas [ Page 3 ] 163 The server generates a random number which is used as a confounder. 164 Then an AuthConfirm is computed applying N times the one-way 165 function to the concatenation of the computed PassKey, the 166 Confounder-S, the Time-C, Confounder-C, the name of the server and 167 the PassKey : 169 AuthConfirm = OWF (PassKey, Confounder-S, Time-C, Confounder-C, 170 PassKey) 172 The GSS-API Context establishment return token defined in section 5 173 of this document includes the Confounder-S and AuthConfirm items. If 174 no error occurs while building that token, GSS_AcceptSecContext 175 returns GSS_S_COMPLETE to the invoker. 177 Upon reception of the GSS-API context establishment return token, 178 the client combines the Confounder-S and Time-C items in a 179 "UniqueNumber". The client uses this UniqueNumber to perform a 180 context establishment replay detection. 182 If that replay check fails (i.e. if that UniqueNumber was not 183 previously received), the client uses the received Confounder-S and 184 Time-C to compute an AuthVerif : 186 AuthVerif = OWF (PassKey, Confounder-S, Time-C, Confounder-C, 187 PassKey) 189 The authentication of the client succeeds if AuthVerif is the same 190 as the received AuthConfirm sent by the server. 192 2. Change SharedSecret Mechanism 194 When a user wishes to change the SharedSecret he shares with a peer, 195 he simply needs to send a change SharedSecret token that contains 196 both the current and the new SharedSecret encrypted with a key 197 derived from the current PassKey. This change SharedSecret operation 198 is performed at any time after the context establishment process. 200 The scheme used for message privacy (see section 5.3.2.2) is used 201 for encrypting the SharedSecret using the current confidentiality 202 dialogue key. 204 The change operation will be accepted by the target only if two 205 conditions occur : the seal is correct, the current SharedSecret sent 206 by the client matches the current SharedSecret known to the target. 208 If the change is accepted by the target then the change SharedSecret 209 acceptance token is returned. Otherwise an error token is returned. 211 If mutual authentication is being used for the context establishment 212 the target may indicate in a secondary status either that the 213 credentials are going to expire soon or that they have expired. In 214 the former case the client can still use subsequent MIC or WRAP 215 tokens. In the later case, the client has to send a change SharedSecret 216 token otherwise MIC and WRAP tokens will be rejected. 218 Lebastard, Pinkas [ Page 4 ] 219 3. Security Services 221 The GSS-API-Easy Mechanism supports mutual and anonymous 222 authentication. The integrity, privacy, replay detection and out-of- 223 sequence detection security services are provided for user messages 224 protection. GSS-API-Easy Mechanism also supports the inter-process 225 context transfer and the use of incomplete contexts. Refer to 226 [GSSV2-C] for a definition of this security services. 228 GSS-API-Easy does not support delegation. 230 Support of anonymity by the GSS-API-Easy Mechanism complies with 231 [GSSV2-C]: ''In addition to informing the application that a context 232 is established anonymously (via the ret_flags outputs from 233 gss_init_sec_context and gss_accept_sec_context), the optional 234 src_name output from gss_accept_sec_context and gss_inquire_context 235 will, for such contexts, return a reserved internal-form name, 236 defined by the implementation. When presented to gss_display_name, 237 this reserved internal-form name will result in a printable name 238 that is syntactically distinguishable from any valid principal name 239 supported by the implementation, associated with a name-type object 240 identifier with the value GSS_C_NT_ANONYMOUS (...). For example, the 241 string "" might be a good choice, if no valid principal 242 name supported by the implementation can begin with "<" and end with 243 ">". '' 245 Channel bindings are not used by the GSS-API-Easy GSS-API mechanism: 246 they are therefore not transmitted in the context establishment 247 tokens and any channel bindings provided to GSS-API routine calls 248 are ignored by the GSS-API-Easy Mechanism implementation. 250 4. Session Keys 252 The initiator (resp. acceptor) computes separate integrity and 253 confidentiality dialogue keys upon successful completion of 254 GSS_InitSecContext (resp. GSS_AcceptSecContext) routine call. 256 The Integrity Dialogue Key is computed using : 258 IDK = OWF ( PassKey, server-name, Time-C, Confounder-C, PassKey ) 260 The Confidentiality Dialogue Key is computed using : 262 CDK = OWF ( PassKey, server-name, Confounder-C, Time-C, PassKey ) 264 It is to be noted that both dialogue keys may be computed at the 265 client side if GSS_InitSecContext routine returns 266 GSS_S_CONTINUE_NEEDED in case of mutual authentication. This allows 267 the GSS-API-Easy Mechanism to support the GSS_C_PROT_READY_FLAG. 269 Lebastard, Pinkas [ Page 5 ] 270 5. GSS-API Token Formats 272 This section discusses protocol-visible characteristics of the 273 GSS-API-Easy GSS-API mechanism ; it defines elements of protocol for 274 interoperability and is independent of language bindings per 276 [GSSV2-C]. 278 Tokens transferred between GSS-API peers (for security context 279 management, error and per-message protection purposes) are defined. 281 The GSS-API-Easy GSS-API mechanism as defined in this and any 282 successor memos will be identified with the following Object 283 Identifier : 285 { 1(iso), 3(org), 6(dod), 1(internet), 5(security), 5(mechanism), 286 3(gss-api-easy) } 287 [T.B.C.] 289 Per [GSSV2], section 3.1, the initial context establishment token is 290 enclosed within framing as follows : 292 InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { 293 thisMech MechType, 294 -- MechType is OBJECT IDENTIFIER 295 -- representing GSS-API-Easy 296 innerContextToken ANY DEFINED BY thisMech 297 -- contents mechanism-specific 298 -- ASN.1 structure not required 299 } 301 The above framing is applied to all tokens emitted by the 302 GSS-API-Easy GSS-API mechanism, including change SharedSecret, error 303 and per-message tokens, not just to the initial token in a context 304 establishment sequence. While not required by [GSSV2], this enables 305 implementations to perform enhanced error-checking. 307 Per [GSSV2], GSS_DeleteSecContext does not produce any token. 309 The innerContextToken consists in the BER encoding of the 310 GssApiEasyToken ASN.1 data structure below : 312 GssApiEasyToken ::= SEQUENCE { 313 tokenType [0] ENUMERATED { 314 INIT-Req-Token (0), 315 INIT-Resp-Token (1), 316 CHANGE-Req-Token (2), 317 CHANGE-Resp-Token (3), 318 MIC-Token (4), 319 WRAP-Token (5), 320 ERR-Token (6) 321 }, 323 Lebastard, Pinkas [ Page 6 ] 324 tokenContents [1] CHOICE { 325 initReqToken [0] InitReqToken, 326 initRespToken [1] InitRespToken, 327 passReqToken [2] PassReqToken, 328 passRespToken [3] PassRespToken, 329 micToken [4] MicToken, 330 wrapToken [5] WrapToken, 331 errToken [6] ErrToken 332 } 333 } 335 5.1. Context Establishment Tokens 337 5.1.1. Initial Token 339 The initial context establishment token contains the above 340 GssApiEasyToken data structure with tokenType set to 341 INIT-Req-Token and tokenContents set to the InitReqToken data 342 structure defined as : 344 InitReqToken ::= SEQUENCE { 345 initiatorName [0] OCTET STRING, 346 targetName [1] OCTET STRING, 347 contextFlags [2] BIT STRING { 348 mutual (2), 349 replay (3), 350 sequence (4), 351 confidentiality (5), 352 anonymity (6) 353 }, 354 timeStamp [3] UTCTime, 355 confounder [4] OCTET STRING, 356 owfId [5] ENUMERATED { 357 sha1 (1), 358 md5 (2) 359 } OPTIONAL, 360 owfIterations [6] INTEGER OPTIONAL, 361 authData [7] OCTET STRING 362 } 364 The authData field contains the result of the computation of the 365 OWF on the BER-encoding of the following AuthProofData item : 367 AuthProofData ::= SEQUENCE { 368 passKey [0] OCTET STRING, 369 timeC [1] UTCTime, 370 confounderC [2] OCTET STRING, 371 passKey [3] OCTET STRING 372 } 374 where passKey contains the result of N computations of the OWF on 375 the BER-encoding of the following PassKeyData item : 377 Lebastard, Pinkas [ Page 7 ] 378 PassKeyData ::= SEQUENCE { 379 clientName [0] OCTET STRING, 380 passPhrase [1] OCTET STRING, 381 serverName [2] OCTET STRING 382 } 384 The ClientName item used in the computation of the PassKey uses the 385 content of the above initiatorName field. 387 The ServerName item used in the computation of PassKey uses the 388 content of the above targetName field. 390 The contextFlags bit vector included in the initial context 391 establishment token corresponds to the service flags as defined in 392 [GSSV2] : 394 GSS_C_DELEG_FLAG 1 395 GSS_C_MUTUAL_FLAG 2 396 GSS_C_REPLAY_FLAG 4 397 GSS_C_SEQUENCE_FLAG 8 398 GSS_C_CONF_FLAG 16 399 GSS_C_INTEG_FLAG 32 400 GSS_C_ANON_FLAG 64 401 GSS_C_PROT_READY_FLAG 128 402 GSS_C_TRANS_FLAG 256 404 As said before, GSS-API-Easy GSS-API mechanism does not support the 405 delegation service. 407 5.1.2. Authentication Response Token 409 Applications requiring confirmation that their authentication was 410 successful should request mutual authentication, resulting in a 411 "mutual" indication within the contextFlags of the AuthToken. 413 In response to such a request, the target replies to the initiator 414 with a token containing an GssApiEasyToken data structure where 415 tokenType is set to INIT-Resp-Token and tokenContents set to the 416 InitRespToken data structure defined as : 418 InitRespToken ::= SEQUENCE { 419 confounderS [0] OCTET STRING, 420 authData [1] OCTET STRING 421 } 423 In that token, the confounderS is a new randomly generated 424 confounder and authData contains the result of the OWF on the BER- 425 encoding of the following AuthVerifData : 427 AuthVerifData ::= SEQUENCE { 428 passKey [0] OCTET STRING, 429 confounderS [1] OCTET STRING, 430 timeC [2] UTCTime, 432 Lebastard, Pinkas [ Page 8 ] 433 confounderC [3] OCTET STRING, 434 passKey [4] OCTET STRING 435 } 437 where timeC, and confounderC are retrieved from the incoming 438 InitReqToken, and passKey is computed as described in the 439 above section 5.1.1. 441 5.2. Change SharedSecret Tokens 443 The change SharedSecret procedure may occur at any time after the 444 secure context establishment, i.e. once the session keys are 445 established at both sides. Though these tokens are not produced 446 by GSS-API routine calls, they use the GSS-API token framing 447 defined in [GSSV2]. 449 5.2.1. Change SharedSecret Request 451 The change SharedSecret token contains the above GssApiEasyToken 452 structure with tokenType set to CHANGE-Req-Token and tokenContents 453 set to the PassReqToken data structure defined as : 455 PassReqToken ::= SEQUENCE { 456 sharedSecretData [0] OCTET STRING, 457 seal [1] OCTET STRING 458 } 460 where sharedSecretData contains the encrypted BER-encoding of the 461 following data structure : 463 SharedSecretData ::= SEQUENCE { 464 confounder [0] OCTET STRING, 465 currentSharedSecret [1] OCTET STRING, 466 newSharedSecret [2] OCTET STRING 467 } 469 where confounder contains a random 8 bytes array. 471 The encryption rule used during the change SharedSecret operation is 472 the rule described for privacy WRAP token in section 5.3.2.2. of 473 this document. 475 The above seal field is computed on the SharedSecretData item using 476 the rule described for integrity WRAP token in section 5.3.2.1. of 477 this document. 479 5.2.2. Change SharedSecret Response 481 Upon reception of a change SharedSecret request, the server verifies 482 the seal of the SharedSecretToken and decrypts the SharedSecretData. 483 Then a new passphrase acceptance token is returned to the emitter. 484 This token consists in an GssApiEasyToken with tokenType set to 485 CHANGE-Resp-Token and tokenContents contains the ChangeRespToken data 486 item defined as : 488 Lebastard, Pinkas [ Page 9 ] 489 ChangeRespToken ::= OCTET STRING 491 That token contains the MIC of the above ChangeReqToken. That 492 MIC is computed using the rule described for MIC Token in section 493 5.3.1 of this document. 495 In case of error, an Error Token is returned to the emitter of the 496 change SharedSecret request. See section 5.4 of this document for 497 detailed error status. 499 5.3. Per-Message Tokens 501 Two classes of tokens are defined in this section : "MIC" tokens, 502 emitted by calls to GSS_GetMIC() and consumed by calls to 503 GSS_VerifyMIC(), and "WRAP" tokens, emitted by calls to GSS_Wrap() 504 and consumed by calls to GSS_Unwrap(). 506 5.3.1. MIC Tokens 508 Use of the GSS_GetMIC() call yields a token, separated from the user 509 data being protected, which can be used to verify the integrity of 510 that data as received. For MIC tokens, tokenType is set to MIC-Token 511 and tokenContents is set to the following MicToken : 513 MicToken ::= SEQUENCE { 514 seqNumber [0] INTEGER OPTIONAL, 515 mic [1] OCTET STRING 516 } 518 The mic field is computed using the following formula : 520 mic = OWF ( IDK, Data-Encoding, IDK ) 522 where Data-Encoding is the BER encoding of the MicData item : 524 MicData ::= SEQUENCE { 525 seqNumber [0] INTEGER OPTIONAL, 526 userText [1] OCTET STRING 527 } 529 where userText contains the provided user message and its sequence 530 number if GSS_C_SEQUENCE_FLAG is active for the current context. 532 The OWF used to compute the mic is the same as the OWF used during 533 the secure context establishment. 535 Upon reception of a MicToken, the peer BER-encodes a MicData item 536 with userText set to the provided user's text and seqNumber set to 537 the received sequence number if GSS_C_SEQUENCE_FLAG is active for 538 the current context. It then computes a seal with the above formula 539 and verifies that this seal matches the received mic. 541 Lebastard, Pinkas [ Page 10 ] 542 5.3.2. WRAP Tokens 544 Use of the GSS_Wrap() call yields a token which encapsulates the 545 input user data (optionally encrypted) along with associated 546 integrity check quantities. For WRAP tokens, tokenType is set to 547 WRAP-Token and tokenContents is set to the following WrapToken : 549 WrapToken ::= SEQUENCE { 550 userData [0] WrapData, 551 seal [1] OCTET STRING 552 } 554 WrapData ::= SEQUENCE { 555 userText [0] OCTET STRING, 556 textMode [1] ENUMERATED { 557 isClear (1), 558 isEncrypted (2) 559 }, 560 seqNumber [2] INTEGER OPTIONAL 561 } 563 5.3.2.1. Message Integrity Only 565 If the conf_req input argument to GSS_Wrap is set to FALSE, GSS_Wrap 566 yields a WrapToken encapsulating the input user data. The seal field 567 is computed using the following formula : 569 seal = OWF ( IDK, Data-Encoding, IDK ) 571 where Data-Encoding is the BER encoding of the WrapData item where 572 userText is set to the input user data, textMode is set to isClear, 573 textLen is set to the length of the input user data and seqNumber is 574 set to the message sequence number if GSS_C_SEQUENCE_FLAG is active 575 for the current context. 577 The OWF used to compute the mic is the same as the OWF used during 578 the secure context establishment. 580 Upon reception of a WrapToken with textMode set to isClear, the peer 581 BER-encodes the received WrapData item, computes a seal with the 582 above formula and verifies that it matches the received seal. 584 5.3.2.2. Message Privacy 586 If the conf_req input argument to GSS_Wrap is set to TRUE, GSS_Wrap 587 yields a WrapToken encapsulating the encrypted user data. The seal 588 field is computed using the following formula : 590 seal = OWF ( CDK, Data-Encoding, IDK ) 592 where Data-Encoding is the BER encoding of the WrapData item where 593 userText is set to the encrypted user data, textMode is set to 594 isEncrypted, textLen is set to the length of the input user data and 596 Lebastard, Pinkas [ Page 11 ] 597 seqNumber is set to the message sequence number if 598 GSS_C_SEQUENCE_FLAG is active for the current context. 600 The OWF used to compute the seal is the same as the OWF used during 601 the secure context establishment. 603 The user data encryption algorithm is based on the use of the same 604 OWF. The emitter prepares the following UserMessage item which is 605 composed of a confounder (random number) followed and concatenated 606 with the original text to be encrypted. 608 If L is the size in bytes of the output of the hash function being 609 used by the security mechanism, then the confounder contains L bytes 610 that are placed in front of the original text to be encrypted, 611 followed by that original text that is divided into blocks of 612 L bytes. 614 The first block B0 is encrypted to form an encrypted block C0. The 615 computation for this first block is performed by XORing B0 with 616 a OWF applied to the Confidentiality Dialogue Key as follows : 618 C0 = B0 XOR OWF(CDK) 620 Each subsequent block Bn is encrypted to form an encrypted block 621 Cn as follows : 623 Cn = Bn XOR OWF(Cn-1, CDK) 625 The last block may contain exactly L bytes or less. 627 If it contains exactly L bytes, then an additional block of L bytes 628 is added, where the last byte contains the number of bytes from the 629 last block to be discarded by the receiver (in that case L) and the 630 other bytes contain ones. 632 If it contains less than L bytes, then the last byte contains the 633 number of bytes from the last block to be discarded by the receiver 634 (in that case a value between 1 and L-1) and the bytes between the 635 last byte of the original text and that last byte are filled in with 636 ones. 638 Upon reception of a WrapToken with textMode set to isEncrypted, the 639 peer first verifies the message seal using the integrity dialogue 640 key. It then computes the set of encryption keys with the above 641 formulas and applies the same encryption procedure. It finally 642 obtains the confounder followed by the original text padded to 643 a multiple of L bytes. It discards the confounder and truncates the 644 original text to its original size using the padding information 645 present in the last byte. 647 5.4. Error Tokens 649 GSS-API-Easy GSS-API mechanism supports error tokens in order to 650 allow enhanced error checking. 652 Lebastard, Pinkas [ Page 12 ] 653 Any GSS-API routine emitting tokens (GSS_InitSecContext, 654 GSS_AcceptSecContext, GSS_Wrap, GSS_GetMIC, GSS_ExportSecContext, 655 as well as the change SharedSecret procedure) may produce an error 656 token. 658 For Error Tokens, tokenType is set to ERR-Token and tokenContents 659 is set to the following ErrToken : 661 ErrToken ::= SEQUENCE { 662 errData [0] ErrorData, 663 seal [1] OCTET STRING 664 } 666 ErrorData ::= ENUMERATED { 667 GSS_E_FAILURE (1), 668 GSS_E_DECODING (2), 669 GSS_E_REPLAY (3), 670 GSS_E_AUTH (4), 671 GSS_E_ANON (5), 672 GSS_E_VERIFY (6), 673 GSS_E_DECRYPT (7), 674 GSS_E_CLOCK_SKEW (8), 675 GSS_E_NEW_PWD (9), 676 GSS_E_WRONG_PWD (10), 677 GSS_E_PWD_POLICY (11) 678 } 680 where : 682 GSS_E_FAILURE identifies a (OS-related) system error 684 GSS_E_DECODING identifies a BER decoding error 686 GSS_E_AUTH identifies an authentication failure 688 GSS_E_ANON indicates that anonymous authentication is not 689 authorized by the acceptor 691 GSS_E_REPLAY identifies a context establishment replay error 693 GSS_E_VERIFY identifies an integrity error on the DataToken 695 GSS_E_DECRYPT identifies a decryption error on the DataToken 697 GSS_E_CLOCK_SKEW indicates that the clock skew between the 698 peers' machines is too large to check context 699 establishment replay detection. 701 GSS_E_NEW_PWD indicates that the current SharedSecret has 702 expired and should be modified 704 GSS_E_WRONG_PWD indicates that the current SharedSecret provided 705 for the change SharedSecret procedure is not the 706 current SharedSecret. 708 Lebastard, Pinkas [ Page 13 ] 709 The seal of an ErrToken is computed according to the MIC rule on the 710 BER-encoding of the ErrData data structure. 712 If the GSS_E_NEW_PWD error status is received by a client, then the 713 GSS-API routine call should return GSS_S_CREDENTIALS_EXPIRED to the 714 invoker (or GSS_S_CONTEXT_EXPIRED if the request to change the 715 SharedSecret occurs during a user message exchange). 717 6. Name Types 719 This section discusses the name types which may be passed as input 720 to the GSS-API-Easy GSS-API Mechanism GSS_Import_name() call, and 721 their associated identifier values. In addition to specifying OID 722 values for name type identifiers, symbolic names are included and 723 recommenced to GSS-API implementors in the interest of convenience 724 to callers. 726 GSS-API-Easy supports a subset of name types defined in [GSSV2] : 728 GSS_C_NT_EXPORT_NAME { 1,3,6,1,5,6,4 } 729 GSS_C_NT_ANONYMOUS { 1,3,6,1,5,6,3 } 730 GSS_C_NT_USER_NAME { 1,2,840,113554,1,2,1,1 } 731 GSS_C_NT_HOSTBASED_SERVICE { 1,3,6,1,5,6,2 } 733 Any of the above name types may be provided as input to the 734 GSS-API-Easy Mechanism GSS_Import_name() call. The name value 735 provided to GSS_Import_name() call shall consist of a non 736 zero-length printable string. 738 Note that for the GSS_C_NT_HOSTBASED_SERVICE name type (name of the 739 form service@hostname), the "hostname" may be omitted but the "@" 740 must always be present. 742 7. SECURITY CONSIDERATIONS 744 The GSS-API-Easy authentication protocol is subject to dictionary 745 attacks. Users should be required to choose passphrases with a 746 minimum length of eight characters and be educated to choose their 747 passphrases using more than the basic 26 letters from the alphabet. 749 If they use upper and lower case characters including the 10 750 digits and a few special characters, a passphrase complexity 751 equivalent to 64 characters mixed on eight positions may be 752 achieved. This is equivalent to 2 to 6, raised at the power 8, 753 hence a key length equivalent to 48 bits. 755 In order to reduce the rate of exhaustive search attacks, an 756 additional step is introduced which limits the rate to roughly 4 757 trials per second on a workstation similar to the workstation used 758 by the client. The rate reduction is obtained by applying n times a 759 OWF to the secret shared between the client and the server. 761 Lebastard, Pinkas [ Page 14 ] 762 As an example, the performances the OWF SHA1 and MD5 on a Pentium II 763 333 MHz running Windows 98 have been measured as follows: 765 Applied 10000 SHA1 in 110 ms 766 Applied 100000 SHA1 in 1040 ms 767 Applied 1000000 SHA1 in 6920 ms 769 Applied 10000 MD5 in 110 ms 770 Applied 100000 MD5 in 940 ms 771 Applied 1000000 MD5 in 5820 ms 773 With these figures, on the same single workstation, a year of 774 exhaustive search attacks would allow to find 3600 x 24 x 365 x 4 775 keys that is 126.144.000 keys or 7,5 x 2 to 24 keys, roughly equal 776 to 2 to 27 keys. With 50 % chance, this would take 2 to 20 years, 777 or 1 million years. 779 Such dictionary attack would also only be valid against a single 780 user. 782 Replay detection is achieved by the target by storing in a table 783 information about the most recent successful authentications. 784 Storing both the received time and the confounder during a five 785 minutes window time frame is sufficient since it is very unlikely 786 that two different clients will pick up the same confounder at the 787 same time. 789 Replay detection is achieved by the client by verifying that the 790 same time and confounder as sent by the client are used by the 791 target. 793 Replay protection on a different verifier is achieved through the 794 use of the server name as part of the computation of the 795 authentication data. 797 The change SharedSecret protocol might be subject to replay attacks 798 if two change SharedSecret operations where sent during the same 799 session. The use of the current SharedSecret and its verification by 800 the target prevents the replay attack. 802 The change SharedSecret protocol may be followed by a voluntary or 803 accidental connection break down. In some cases it may be 804 difficult to know whether the SharedSecret has or has not really be 805 changed at the target. The client software should be prepared to 806 handle this kind of situation and alert the user that he might 807 need to remember the old passphrase. 809 REFERENCES 811 [GSSV2] Internet Draft, John LINN, 16 December 1998 812 "Generic Security Service Application Program Interface 813 Version 2, Update 1" 814 (draft-ietf-cat-rfc2078bis-08.txt) 816 Lebastard, Pinkas [ Page 15 ] 818 [GSSV2-C] Internet Draft, John WRAY, November 1998 819 "Generic Security Service API Version 2 : C bindings" 820 (draft-ietf-cat-gssv2-cbind-08.txt) 822 AUTHORS' ADDRESSES 824 Jacques Lebastard 825 BULL S.A. 826 Rue Jean Jaures 827 F-78340 LES CLAYES SOUS BOIS 828 Phone : +33 1 30 80 77 86 829 Fax : +33 1 30 80 77 99 830 Email : Jacques.Lebastard@bull.net 832 Denis Pinkas 833 BULL S.A. 834 Rue Jean Jaures 835 F-78340 LES CLAYES SOUS BOIS 837 Phone : +33 1 30 80 34 87 838 Fax : +33 1 30 80 33 21 839 Email : Denis.Pinkas@bull.net 841 Lebastard, Pinkas [ Page 16 ]