idnits 2.17.1 draft-huehnlein-credman-spkm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 555 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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 an Authors' Addresses Section. ** The abstract seems to contain references ([GSS-API1,2], [SPKM], [PKIX], [SSLogin], [X509v3]), 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 44: '... propose two new RECOMMENDED algorithm...' RFC 2119 keyword, line 89: '...re we will propose two new RECOMMENDED...' RFC 2119 keyword, line 406: '...We propose the RECOMMENDED algorithms,...' RFC 2119 keyword, line 413: '...as OPTIONAL algorithms for SPKM as soo...' 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 (March 1998) is 9539 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 section? 'GSS-API1' on line 505 looks like a reference -- Missing reference section? '2' on line 48 looks like a reference -- Missing reference section? 'SPKM' on line 527 looks like a reference -- Missing reference section? 'X509v3' on line 534 looks like a reference -- Missing reference section? 'PKIX' on line 522 looks like a reference -- Missing reference section? 'SSLogin' on line 530 looks like a reference -- Missing reference section? 'KERBEROS-V5' on line 514 looks like a reference -- Missing reference section? 'IEEEP1363' on line 511 looks like a reference -- Missing reference section? 'SECUDE' on line 524 looks like a reference -- Missing reference section? 'PKCS1' on line 520 looks like a reference -- Missing reference section? 'GSS-API2' on line 508 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft D. Huehnlein (secunet GmbH) 2 H. Schupp (GMD GmbH) 3 expires in six months March 1998 5 Credential Management for SPKM 7 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the entire list of current Internet Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Comments on this document should be sent to "cat-ietf@mit.edu", the 28 IETF Common Authentication Technology WG discussion list or to the 29 authors "huehnlein@secunet.de" and "schupp@darmstadt.gmd.de". 31 ABSTRACT 33 The GSS-API [GSS-API1,2] offers security services independent of 34 underlying mechanisms. A possible GSS-mechanism is the Simple Public 35 Key Mechanism [SPKM]. This paper complements [SPKM] by providing 36 concrete rules for the Credential Management. Our proposal allows 37 beside the standard Credential Management based on X.509v3 [X509v3] 38 and PKIX [PKIX] the self certification of temporary public keys, 39 which may be used to implement a Secure Single Login variant, which 40 works with temporary keys instead of the sensitive long term keys. 41 The benefits of this approach are discussed in [SSLogin] more 42 detailed. Since DL-based signature- and encryption algorithms are 43 very well suited for the efficient generation of the temporary keys 44 we propose two new RECOMMENDED algorithms for SPKM. 46 1 INTRODUCTION 48 The GSS-API [GSS-API1,2] "offers security services to callers in a 49 generic fashion, supportable with a range of underlying mechanisms and 50 technologies and hence allowing source-level portabiltiy of applications 51 to different environments". 53 Possible GSS mechanisms are e.g. the well known Kerberos V5 54 [KERBEROS-V5] based on symmetric cryptography or the Simple Public Key 55 Mechanism [SPKM]. 57 During context establishment the communication partners verify the 58 peer's identity and authorization and agree on a common session key, 59 which may be used for confidentiality and integrity purposes during the 60 actual communication. To proof the identity one has to acquire 61 credentials. In Kerberos these credentials are so called tickets with 62 LIMITED LIFETIME. 64 In public-key based mechanisms like SPKM the credentials are the secret 65 keys and certificates for the public keys. The secret keys are stored in 66 a personal security environment (PSE), which is 'opened', i.e. made 67 accessible, by entering a password. In practice the PSE usually is a 68 smartcard or a PKCS#5 encrypted file. These credentials have to be 69 available whenever a new GSS-connection is requested, i.e. a GSS-context 70 is to be established (which can be quite often, since a client usually 71 requests multiple GSS-connections to different servers at different 72 times). 74 This means, that either the PSE has to be open for a long time or the 75 user has to enter the password everytime a new connection is set up. If 76 this is no problem, this is the most obvious way to provide access to 77 the secret keys and, while not specified in SPKM, X.509 v3 / PKIX 78 certification for the related public keys. 80 However if keeping the PSE open for a long time bears security problems 81 or multiple entering of the password is not possible for usability 82 reasons the proposed SSLogin variant, as discussed in [SSLogin], is 83 preferable. To implement this SSLogin we need to specify a slightly 84 different credential management, which allows the end user to CERTIFY 85 ITS OWN TEMPORARY KEYS. 87 To keep the generation of the temporary keys efficient, we propose to 88 use Discrete Logarithm based algorithms for the context establishment 89 rather than RSA. Therefore we will propose two new RECOMMENDED 90 algorithms for SPKM in section 3. For convenience we will include the 91 comparison between the different variants in the appendix. For details 92 we refer to [SSLogin]. 94 2. CREDENTIAL MANAGEMENT FOR SPKM 96 In this section we will specify the credential management for SPKM. In 97 [SPKM] there is not very much said about this problem. 99 "The key management employed in SPKM is intended to be as compatible 100 as possible with both X.509 and PEM, since these represent large 101 communities of interest and show relative maturity in standards." 103 2.1 STARTING POINT - X.509 v3 / PKIX 105 Before we treat the new credential management in detail, we will point 106 out why X.509 v3 / PKIX certification only "almost" fit our needs. 108 The 'Basic Constraints' extension is specified by X.509 v3 and required 109 by PKIX. It allows to distinguish between an end user- and a 110 CA-certificate. It contains a boolean flag 'cA' which determines (when 111 FALSE), that the certificate belongs to an end user. Since this 112 extension is recommended to be critical an end user cannot act as a CA 113 without notice. If an end user signs a certificate it will not be 114 valid. 116 Another extension is 'Key Usage', which allows to restrict the usage of 117 the key contained in the certificate and is recommended to be 118 critical. The information is provided by a combination of distinguished 119 bits, each standing for a special purpose. The most interesting bits for 120 us are digitalSignature(0), nonRepudiation(1), keyCertSign(5), and 121 cRLSign(6). As one can see, the signing of certificates is not covered 122 by the simple 'digitalSignature' bit, but requires the 'keyCertSign' 123 bit, which is only set for CA-certificates. 125 Up to here it seems to be impossible to reach our goal of 126 self-certification of temporary keys, if there were not the 'Extended 127 Key Usage' extension. 128 This extension field was not present in the X.509 recommendations 129 [DAM-X.509] and the PKIX profile [PKIX] until recently. 130 Experiences in deploying the base standard showed, that there are 131 situations, in which it is necessary to specify the key usage somewhat 132 more concrete. 134 We will use this extension (together with a somewhat relaxed evaluation 135 of the Basic Constraints and KeyUsage extensions) to specify a scheme 136 for certificate verification that is as close to PKIX as possible but 137 allows self-certification of temporary keys to implement our proposed 138 Secure Single Login. 140 It is secure in that it allows circumvention of PKIX in only one, 141 well defined manner and for our special purpose. Furthermore it 142 introduces only one small exception to the PKIX verification procedure, 143 so it will be easy to implement in an existing implementation of the 144 SPKM GSS-API mechanism. 146 Another extension to mention is the 'Subject Alternative Name'. It 147 provides the possibility to specify the subject's identity in another 148 form as the Distinguished Name in the X.509 v1 field 'subject'. If the 149 latter one is left empty, this extension should be critical. 150 The same extension exists for the 'issuer' field ('Issuer Alternative 151 Name'). 153 Last but not least, the extension 'Authority Key Identifier' provides a 154 way to refer to a specific key of the issuer, that shall be used for the 155 verification of a certificate. The issuing certificate can be identified 156 by the name of its issuing authority (the "grandparent" of the 157 certificate we look at right now) and its serial number or by a unique 158 octet string (KeyIdentifier), which should appear in the issuing 159 certificates 'Subject Key Identifier' extension. 161 2.2 SECURE SINGLE LOGIN 163 During our proposed secure single login, the user will 165 1. open the PSE to be able to access the long term signature key. 167 Furthermore the user's software will 169 2. generate a new temporary (assymetric) key(s) for use in SPKM. 171 There is no specific order for these two operations, they even could be 172 performed at the same time in a multi-threaded environment. 173 Then the temporary public key(s) are 175 3. self-certified with the long term signature key. 177 After that, the PSE is closed again and the valuable long term keys are 178 not exposed any more. 180 The philosophy of SSLogin is equal to Kerberos' [KERBEROS-V5], where we 181 use temporary keys (tickets) with a limited lifetime to authenticate. If 182 an attacker manages to access the memory or the harddrive he will only 183 get the temporary secret keys instead of the valuable long term keys. If 184 this disclosure is recognized the temporary certificate may be revoked. 186 Note, that the self-certification in step 3. violates the PKIX-profile, 187 because an end user is not allowed to sign certificates. In the proposed 188 SSLogin-SPKM however it is essential, that this self-certification is 189 allowed. It would take too long for a user to contact a trusted 190 certification authority to get the temporary public key(s) 191 certified. Since the conservative evaluation of the basic constraints 192 and the key-usage extension is not necessary in this context, we can 193 change the proposed SPKM-profile accordingly, like discussed in the next 194 section. 196 2.3 SSLOGIN-SPKM PROFILE 198 We propose to use the PKIX profile with the following incremental 199 changes to allow the self-certification of the temporary public key(s). 201 We define two new key purposes for the 'Extended Key Usage' field: 203 * SignTempCert 205 If this key purpose is present, the contained subject public key is 206 allowed to verify a certificate for a temporary key, even if the 207 cA-flag in the Basic constraints extension is set to FALSE. The Key 208 Usage bit 'digitalSignature' has to be set and 'nonRepudiation' may be 209 set. 211 id-kp-SignTempCert OBJECT IDENTIFIER ::= { id-kp 1 } 213 * Temporary 215 This key purpose indicates, that it is a temporary key and that the 216 next certificate in the verification chain is a user certificate in 217 which id-kp-SignTempCert should be present. 219 id-kp-Temporary OBJECT IDENTIFIER ::= { id-kp 2 } 221 To use already issued certificates without id-kp-SignTempCert being 222 present, it is valid that this key purpose is not present. For new 223 certificates however we recommend to include this key purpose. 225 Since the proposed SSLogin mechanism is tailormade for SPKM we recommend 226 to subordinate these two object identifiers to SPKM behind the two 227 mechanism-variants ({id-spkm 1} for 3 way authentication and {id-spkm 2} 228 for two-way authentication with secure time stamps) specified in [SPKM]. 229 Thus we propose 231 id-kp OBJECT IDENTIFIER ::= { id-spkm 3 }, 233 where 235 id-spkm OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) internet(1) 236 security(5) mechanisms(5) 1 } 238 We will assume, that a user already got X.509 v3 / PKIX certified public 239 keys. Since we want to use the key for signing a certificate, we only 240 need the signature key. The user's corresponding certificate will 241 contain these fields (informally): 243 v1 fields: 244 * U-serialNo 245 * issuer = CA 246 * validity = U-validity 247 * subject = User 248 v3 extensions: 249 * subjectAltName = UserAlt (optional, if subject not empty) 250 * issuerAltName = CAAlt (optional, if issuer not empty) 251 * Key usage 252 - digitalSignature = TRUE 253 * Basic constraints 254 - cA = FALSE 256 To be in conformance to our proposed profile, these additional 257 restrictions are necessary: 259 + the 'Key Usage' extension is made critical and contains at least the 260 bit digital signature(0) 261 + the 'Basic Contraints' extension is made critical 262 + the 'Extended Key Usage' extension is present and contains 263 id-kp-SignTempCerts 264 This extension should be marked non-critical to allow usage of this 265 certificate in applications which are not in conformance with this 266 profile. 268 In summary, the users long term certificate of the public signature key 269 is: 271 v1 fields: 272 * U-serialNo 273 * issuer = CA 274 * validity = U-validity 275 * subject = User 276 v3 extensions: 277 * subjectAltName = UserAlt 278 * issuerAltName = CAAlt 279 * Key usage (critical = TRUE) 280 - digitalSignature = TRUE 281 * Extended key usage (critical = FALSE) 282 - id-kp-SignTempCert 283 * Basic constraints (critical = TRUE) 284 - cA = FALSE 286 It is assumed, that this certificate is issued by a trusted CA, 287 conforming to PKIX. 289 The certificate for the temporary public signature key will 290 (informally) look like this: 292 v1 fields: 293 * T-serialNo 294 * issuer = User 295 * validity = T-validity 296 * subject = User 297 v3 extensions: 298 * subjectAltName = UserAlt 299 * issuerAltName = UserAlt 300 * Key usage (critical = TRUE) 301 - digitalSignature = TRUE 302 (all others = FALSE) 303 * Extended key usage (critical = TRUE) 304 - id-kp-Temporary 305 * Basic constraints (critical = TRUE) 306 - cA = FALSE 307 * Authority key identifier (critical = FALSE) 308 - authorityCertIssuer = CA 309 - authorityCertSerialNumber = U-serialNo 311 The certificate for the temporary public encryption key looks similar, 312 except for the 'Key Usage' extension, which should have set the bits 313 keyEncipherment(2) - or keyAgreement(4), whichever is appropriate, 314 instead of digitalSignature. 316 The use of the 'Authority Key Identifier' extension is recommended (also 317 by PKIX), but not required. It facilitates the search for the users 318 long-term certificate and makes absolutely clear, that this is a 319 self-signed certificate and no prototype certificate like used by some 320 certification request mechanisms. 322 Alternatively or additionally to the issuer/serialNumber pair, the key 323 identifier method can be used for this extension. This is closer to PKIX 324 recommendations. 326 The serial number of the temporary certificates should ideally be 327 consecutively numbered, so that the temporary certificates can be 328 identified uniquely by issuer (User) and serial number, but this is no 329 critical requirement. 331 Clearly, a certificate verification procedure conform to the PKIX 332 profile will reject this temporary certificate, because it is certified 333 (signed) with an end user's signature key. The (long term) user 334 certificate has not set the 'keyCertSign' bit and the 'cA' flag 335 in the Basic constraints extension is FALSE. Therefore we propose a 336 somewhat relaxed certificate verification: 338 A certificate will be valid, if 340 a) all certificates in the verification chain are PKIX conform 342 or if 344 b) all of the following requirements are fulfilled: 346 1. The first (temporary) certificate has the following properties: 347 1.1 issuer == subject, 348 1.2 issuerAltName == subjectAltName, 349 1.3 T-validity is subrange of U-validity, i.e. 350 1.3.1 T-validity.notBefore > U-validity.notBefore, 351 1.3.2 T-validity.notAfter < U-validity.notAfter, 352 1.4 the Key Usage extension is critical, 353 1.5 nonRepudiation == FALSE, 354 1.6 keyCertSign == FALSE, 355 1.7 cRLSign == FALSE, 356 1.8 the Extended Key Usage extension is critical, 357 1.9 'id-kp-Temporary' is present in Extended Key Usage, 358 1.10 the Basic constraints extension is critical, 359 1.11 cA == FALSE, 361 2. all other certificates in the verification chain are PKIX conform, 363 3. and the second (User's long term) Certificate has the following, 364 properties: 365 3.1 the Key Usage extension is critical, 366 3.2 digitalSignature=TRUE, 367 3.3 'id-kp-SignTempKey' is present in Extended Key Usage, 368 3.4 subject == issuer-of-temp-cert, see 1.1 370 It is obvious, that these requirements restrict the presented temporary 371 certificate concept to the first certificate in the verification 372 chain. Since the Basic constraints and Key Usage extension is set 373 appropriate, it will not be possible to act as CA, by maliciously 374 presenting the temporary certificate to an ordinary (PKIX conform) 375 verification procedure. Furthermore the validity period of the temporary 376 certificate is smaller than the validity period of the long term user 377 certificate and it is not possible to issue such temporary certificates 378 for other subjects. Typically the validity period of the temporary 379 certificate will not exceed one day. Through the requirements given in 380 3, it is ensured, that only the long term signature key can be used to 381 produce temporary certificates and that this self-certification is 382 allowed at all. Note, that the verification has to fail, if the subject 383 of the temporary certificate is different from the subject in the long 384 term certificate, which is implicit in our description above and 385 enforced by step 3.4 of the verification procedure. 387 Note, that other extensions, like Policy constraints are not affected by 388 these changes, because we self-certify only user keys. Furthermore it 389 should be mentioned, that the absence of the extended key purpose 390 'id-kp-SignTempkey' could be treated more relaxed to allow the use of 391 already issued certificates without 'id-kp-SignTempkey' for our scheme. 393 It should be mentioned, that it is not possible to (mis-)use the 394 Authorization Data field (included in the first SPKM-token, see 395 [SPKM] page 12) to implement the full functionality proposed, because 396 this Authorization Data field is ONLY present in the FIRST token. Thus 397 the target system can not use temporary keys to authenticate. 399 3. NEW ALGORITHMS FOR SPKM 401 Since Discrete Logarithm based encryption- and signature algorithms are 402 very well suited for the efficient generation of temporary key pairs, 403 we propose two new algorithms to be used for SPKM, like mentioned 404 in [SSLogin]. 406 We propose the RECOMMENDED algorithms, specified in [OSI/OIW]: 408 elGamal ALGORITHM PARAMETER NULL ::= { 1 3 14 7 2 1 } 409 and 410 dsaWithSHA1 ALGORITHM PARAMETER DSAParameters ::= { 1 3 14 7 3 27 } 412 It is intended to propose analogous algorithms based on Elliptic Curves 413 as OPTIONAL algorithms for SPKM as soon as the standardization in 414 e.g. [IEEEP1363] is finished. 416 4. ACKNOWLEDGEMENT 417 We would like to thank C. Adams, P. Eisenacher and T. Surkau for 418 fruitful comments on earlier versions of this draft. 420 APPENDIX A (Security - Usability - Efficiency) 422 In this section we will briefly recall the different variants for the 423 SPKM credential management introduced in [SSLogin], compare them in 424 terms of Security, Usability, Time-Efficiency and Space-Efficiency 425 and give more concrete recommendations for implementation. 427 To compare the time efficiency, we group the operations to be performed 428 in Once, Every GSS-session and Every GSS-context establishment and 429 estimate the workload in terms of modular (1024 bit) 430 multiplications. The times for generation of temporary keys are crude 431 estimates, based on practical measurements with SECUDE [SECUDE]. 433 To compare the space efficiency we estimate the number of bytes, which 434 have to be stored permanently in Secure Storage, i.e. inside the PSE and 435 Insecure Storage, i.e. on the harddisk. We may assume, that a user 436 already got certified long term (1024 bit) RSA key pairs for signatures 437 and encryption and that the SPKM credential management like presented in 438 this specification is applied to all variants. We will only focus on 439 additional time and space requirements. I.e. we neither consider the 440 time needed to generate the long term keys, nor the space required to 441 store them in the PSE. Since we neglect some operations, e.g. computing 442 hash values, generation of random numbers etc. and have to 'convert' the 443 time for some operations to our 'unit' (1024 bit modular 444 multiplication), these estimates are very rough in nature. We may 445 assume, that the secret RSA keys are stored in the RSAPrivateKey-format 446 [PKCS1], so that the decryption and signature operations can be speeded 447 up by application of the Chinese Remainder Theorem. 449 In the following table, these variants are compared: 450 1. Single Login: enter password once and leave PSE open for the whole 451 GSS-session. 452 2. Multiple Login: enter password everytime a GSS-context is 453 established. Close the PSE right afterwards. 454 3. Secure Single Login with RSA: 455 usage of one temporary RSA key pair, used both for signatures and 456 encryption. 457 4. Secure Single Login with a Discrete Logarithm based crypto system 458 (naive, without precomputation): 459 usage of one temporary DSA key pair for signatures and one temporary 460 ElGamal key pair for encryption 461 5. Secure Single Login with a Discrete Logarithm based crypto system 462 (with precomputation): 463 same as 4. but using a precomputed table of group elements 465 Note, that variants 4. and 5. assume a GSS-API implementation, that 466 supports the algorithms ElGamal and DSA (see section 3). 468 Variant | 1. | 2. | 3. | 4. | 5. | 469 ================================================================ 470 Security | low | high | high | high | high | 471 Usability | good | bad | good | good | good | 472 ------------------+--------+--------+--------+--------+--------+ 473 Time-Efficiency | | | | | | 474 (in 1024bit mod. | | | | | | 475 multiplications) | | | | | | 476 | | | | | | 477 Once | / | / | / | 116000 | 116517 | 478 Session | / | / | 108315 | 1267 | 675 | 479 Context | | | | | | 480 - e = Fermat4 | 698 | 698 | 321 | 2408 | 1540 | 481 - general | 5526 | 5526 | 3758 | 7236 | 6368 | 482 ------------------+--------+--------+--------+--------+--------+ 483 Space-Efficiency | | | | | | 484 (in bytes) | | | | | | 485 Secure | / | / | / | 20 | 20 | 486 Insecure | / | / | 740 | 1348 | 19780 | 487 ------------------+--------+--------+--------+--------+--------+ 488 Table 1. Variants for the SPKM credential management 490 >From this table we can see, that we can combine security and usability 491 at only slightly higher expenses at Login-time and context 492 establishment. The application of DL based algorithms turns out to be 493 very well suited to implement the the SSLogin variant, because the time 494 for the actual key generation is negligible small and may be well 495 performed at Login-time. Furthermore it is possible to speed up the 496 context establishment by applying exponentiation variants with 497 precomputation, which is not possible in RSA-type cryptosystems. In this 498 case only slightly more memory is needed to store the precomputed 499 values. Since the additional storage of about 20000 byte should be 500 possible in every implementation, we recommend the application of this 501 exponentiation technique. 503 APPENDIX B (References) 505 [GSS-API1] J. Linn: Generic Security Service Application Program 506 Interface, RFC 1508, Sep. 1993 508 [GSS-API2] J. Linn: Generic Security Service Application Program 509 Interface Version 2, RFC 2078, Jan. 1997 511 [IEEEP1363] IEEE Working Group P1363: Standard for Public Key 512 Cryptography, draft, via http://www.ieee.org 514 [KERBEROS-V5] J. Kohl, C. Neumann: The Kerberos Network Authentication 515 Service (V5), RFC 1510, Sep. 1993 517 [OSI/OIW] OSI/OIW: Part 12 - OSSecurity (Stable), June 1995, via 518 http://www.nemo.ncsl.nist.gov/oiw/agreements/stable/OSI/12s_9506.txt 520 [PKCS1] RSA Lab.: PKCS#1 - RSA Encryption Standard, Version 1.5, 1993 522 [PKIX] R. Housley, W. Ford, S. Farrel, D. Solo: Internet Public Key 523 Infrastructure, Part I: X.509 Certificate and CRL Profile, 524 [SECUDE] GMD/TKT-SIT: SECUrity Development Environment for Open Networks 525 - Online Documentation, http://www.darmstadt.gmd.de/secude/Doc/index.htm 527 [SPKM] C. Adams: The Simple Public-Key GSS-API Mechanism (SPKM), RFC 528 2025, Okt. 1996 530 [SSLogin] D. Huehnlein: Credential Management and Secure Single Login 531 for SPKM, to appear in the Proceedings of NDSS '98, San Diego, March 532 11-13, 1998 534 [X509v3] ISO/IEC 9594-8: Information Technology - Open Systems 535 Interconnection - The Directory: Authentication Framework, CCITT/ITU 536 Recommendation X.509, 1993. 538 [DAM-X.509] ISO/IEC JTC 1/SC 21/WG 4 and ITU-T Q15/7: Final Text of 539 Draft Amendment 1 to ISO/IEC 9594-8 on Certificate Extensions, June 1997