idnits 2.17.1 draft-ietf-cat-kerberos-pk-init-16.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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 1133 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** There are 26 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 3 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), 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 217: '... principal name MUST be set to KRB_NT...' RFC 2119 keyword, line 222: '... the name-string MUST be set as follow...' RFC 2119 keyword, line 227: '... realm MUST be set to the certifica...' RFC 2119 keyword, line 255: '...ees), the following MUST be satisfied....' RFC 2119 keyword, line 259: '..., the realm name MUST be valid (see 2....' (35 more instances...) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC1510bis, but the abstract doesn't seem to mention this, which it should. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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? '1' on line 1012 looks like a reference -- Missing reference section? '2' on line 1015 looks like a reference -- Missing reference section? '6' on line 1030 looks like a reference -- Missing reference section? '7' on line 1034 looks like a reference -- Missing reference section? '5' on line 1027 looks like a reference -- Missing reference section? '11' on line 1051 looks like a reference -- Missing reference section? '15' on line 1066 looks like a reference -- Missing reference section? '0' on line 892 looks like a reference -- Missing reference section? '12' on line 1055 looks like a reference -- Missing reference section? '8' on line 1038 looks like a reference -- Missing reference section? '13' on line 1059 looks like a reference -- Missing reference section? '3' on line 1019 looks like a reference -- Missing reference section? '14' on line 1062 looks like a reference -- Missing reference section? '4' on line 1023 looks like a reference -- Missing reference section? '9' on line 1042 looks like a reference -- Missing reference section? '10' on line 1046 looks like a reference -- Missing reference section? '16' on line 1069 looks like a reference -- Missing reference section? '17' on line 1073 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Brian Tung 2 draft-ietf-cat-kerberos-pk-init-16.txt Clifford Neuman 3 Updates: RFC 1510bis USC/ISI 4 expires March 12, 2002 Matthew Hur 5 Microsoft Corporation 6 Ari Medvinsky 7 Liberate Technologies 8 Sasha Medvinsky 9 Motorola, Inc. 10 John Wray 11 Iris Associates, Inc. 12 Jonathan Trostle 14 Public Key Cryptography for Initial Authentication in Kerberos 16 0. Status Of This Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC 2026. Internet-Drafts are 20 working documents of the Internet Engineering Task Force (IETF), 21 its areas, and its working groups. Note that other groups may also 22 distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 To learn the current status of any Internet-Draft, please check 37 the "1id-abstracts.txt" listing contained in the Internet-Drafts 38 Shadow Directories on ftp.ietf.org (US East Coast), 39 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 40 munnari.oz.au (Pacific Rim). 42 The distribution of this memo is unlimited. It is filed as 43 draft-ietf-cat-kerberos-pk-init-16.txt, and expires March 12, 44 2002. Please send comments to the authors. 46 1. Abstract 48 This document defines extensions (PKINIT) to the Kerberos protocol 49 specification (RFC 1510bis [1]) to provide a method for using public 50 key cryptography during initial authentication. The methods 51 defined specify the ways in which preauthentication data fields and 52 error data fields in Kerberos messages are to be used to transport 53 public key data. 55 2. Introduction 57 The popularity of public key cryptography has produced a desire for 58 its support in Kerberos [2]. The advantages provided by public key 59 cryptography include simplified key management (from the Kerberos 60 perspective) and the ability to leverage existing and developing 61 public key certification infrastructures. 63 Public key cryptography can be integrated into Kerberos in a number 64 of ways. One is to associate a key pair with each realm, which can 65 then be used to facilitate cross-realm authentication; this is the 66 topic of another draft proposal. Another way is to allow users with 67 public key certificates to use them in initial authentication. This 68 is the concern of the current document. 70 PKINIT utilizes ephemeral-ephemeral Diffie-Hellman keys in 71 combination with RSA keys as the primary, required mechanism. Note 72 that PKINIT supports the use of separate signature and encryption 73 keys. 75 PKINIT enables access to Kerberos-secured services based on initial 76 authentication utilizing public key cryptography. PKINIT utilizes 77 standard public key signature and encryption data formats within the 78 standard Kerberos messages. The basic mechanism is as follows: The 79 user sends an AS-REQ message to the KDC as before, except that if that 80 user is to use public key cryptography in the initial authentication 81 step, his certificate and a signature accompany the initial request 82 in the preauthentication fields. Upon receipt of this request, the 83 KDC verifies the certificate and issues a ticket granting ticket 84 (TGT) as before, except that the encPart from the AS-REP message 85 carrying the TGT is now encrypted utilizing either a Diffie-Hellman 86 derived key or the user's public key. This message is authenticated 87 utilizing the public key signature of the KDC. 89 Note that PKINIT does not require the use of certificates. A KDC 90 may store the public key of a principal as part of that principal's 91 record. In this scenario, the KDC is the trusted party that vouches 92 for the principal (as in a standard, non-cross realm, Kerberos 93 environment). Thus, for any principal, the KDC may maintain a 94 symmetric key, a public key, or both. 96 The PKINIT specification may also be used as a building block for 97 other specifications. PKINIT may be utilized to establish 98 inter-realm keys for the purposes of issuing cross-realm service 99 tickets. It may also be used to issue anonymous Kerberos tickets 100 using the Diffie-Hellman option. Efforts are under way to draft 101 specifications for these two application protocols. 103 Additionally, the PKINIT specification may be used for direct peer 104 to peer authentication without contacting a central KDC. This 105 application of PKINIT is based on concepts introduced in [6, 7]. 106 For direct client-to-server authentication, the client uses PKINIT 107 to authenticate to the end server (instead of a central KDC), which 108 then issues a ticket for itself. This approach has an advantage 109 over TLS [5] in that the server does not need to save state (cache 110 session keys). Furthermore, an additional benefit is that Kerberos 111 tickets can facilitate delegation (see [6]). 113 3. Proposed Extensions 115 This section describes extensions to RFC 1510bis for supporting the 116 use of public key cryptography in the initial request for a ticket 117 granting ticket (TGT). 119 In summary, the following change to RFC 1510bis is proposed: 121 * Users may authenticate using either a public key pair or a 122 conventional (symmetric) key. If public key cryptography is 123 used, public key data is transported in preauthentication 124 data fields to help establish identity. The user presents 125 a public key certificate and obtains an ordinary TGT that may 126 be used for subsequent authentication, with such 127 authentication using only conventional cryptography. 129 Section 3.1 provides definitions to help specify message formats. 130 Section 3.2 describes the extensions for the initial authentication 131 method. 133 3.1. Definitions 135 The extensions involve new preauthentication fields; we introduce 136 the following preauthentication types: 138 PA-PK-AS-REQ 14 139 PA-PK-AS-REP 15 141 The extensions also involve new error types; we introduce the 142 following types: 144 KDC_ERR_CLIENT_NOT_TRUSTED 62 145 KDC_ERR_KDC_NOT_TRUSTED 63 146 KDC_ERR_INVALID_SIG 64 147 KDC_ERR_KEY_TOO_WEAK 65 148 KDC_ERR_CERTIFICATE_MISMATCH 66 149 KDC_ERR_CANT_VERIFY_CERTIFICATE 70 150 KDC_ERR_INVALID_CERTIFICATE 71 151 KDC_ERR_REVOKED_CERTIFICATE 72 152 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73 153 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE 74 154 KDC_ERR_CLIENT_NAME_MISMATCH 75 155 KDC_ERR_KDC_NAME_MISMATCH 76 157 We utilize the following typed data for errors: 159 TD-PKINIT-CMS-CERTIFICATES 101 160 TD-DH-PARAMETERS 102 161 TD-TRUSTED-CERTIFIERS 104 162 TD-CERTIFICATE-INDEX 105 164 We utilize the following encryption types (which map directly to 165 OIDs): 167 dsaWithSHA1-CmsOID 9 168 md5WithRSAEncryption-CmsOID 10 169 sha1WithRSAEncryption-CmsOID 11 170 rc2CBC-EnvOID 12 171 rsaEncryption-EnvOID (PKCS#1 v1.5) 13 172 rsaES-OAEP-ENV-OID (PKCS#1 v2.0) 14 173 des-ede3-cbc-Env-OID 15 175 These mappings are provided so that a client may send the 176 appropriate enctypes in the AS-REQ message in order to indicate 177 support for the corresponding OIDs (for performing PKINIT). The 178 above encryption types are utilized only within CMS structures 179 within the PKINIT preauthentication fields. Their use within 180 the Kerberos EncryptedData structure is unspecified. 182 In many cases, PKINIT requires the encoding of the X.500 name of a 183 certificate authority as a Realm. When such a name appears as 184 a realm it will be represented using the "Other" form of the realm 185 name as specified in the naming constraints section of RFC 1510bis. 186 For a realm derived from an X.500 name, NAMETYPE will have the value 187 X500-RFC2253. The full realm name will appear as follows: 189 + ":" + 191 where nametype is "X500-RFC2253" and string is the result of doing 192 an RFC2253 encoding of the distinguished name, i.e. 194 "X500-RFC2253:" + RFC2253Encode(DistinguishedName) 196 where DistinguishedName is an X.500 name, and RFC2253Encode is a 197 function returing a readable UTF encoding of an X.500 name, as 198 defined by RFC 2253 [11] (part of LDAPv3 [15]). 200 Each component of a DistinguishedName is called a 201 RelativeDistinguishedName, where a RelativeDistinguishedName is a 202 SET OF AttributeTypeAndValue. RFC 2253 does not specify the order 203 in which to encode the elements of the RelativeDistinguishedName and 204 so to ensure that this encoding is unique, we add the following rule 205 to those specified by RFC 2253: 207 When converting a multi-valued RelativeDistinguishedName 208 to a string, the output consists of the string encodings 209 of each AttributeTypeAndValue, in the same order as 210 specified by the DER encoding. 212 Similarly, in cases where the KDC does not provide a specific 213 policy-based mapping from the X.500 name or X.509 Version 3 214 SubjectAltName extension in the user's certificate to a Kerberos 215 principal name, PKINIT requires the direct encoding of the X.500 216 name as a PrincipalName. In this case, the name-type of the 217 principal name MUST be set to KRB_NT-X500-PRINCIPAL. This new 218 name type is defined in RFC 1510bis as: 220 KRB_NT_X500_PRINCIPAL 6 222 For this type, the name-string MUST be set as follows: 224 RFC2253Encode(DistinguishedName) 226 as described above. When this name type is used, the principal's 227 realm MUST be set to the certificate authority's distinguished 228 name using the X500-RFC2253 realm name format described earlier in 229 this section. 231 Note that the same string may be represented using several different 232 ASN.1 data types. As the result, the reverse conversion from an 233 RFC2253-encoded principal name back to an X.500 name may not be 234 unique and may result in an X.500 name that is not the same as the 235 original X.500 name found in the client certificate. 237 RFC 1510bis describes an alternate encoding of an X.500 name into a 238 realm name. However, as described in RFC 1510bis, the alternate 239 encoding does not guarantee a unique mapping from a 240 DistinguishedName inside a certificate into a realm name and 241 similarly cannot be used to produce a unique principal name. PKINIT 242 therefore uses an RFC 2253-based name mapping approach, as specified 243 above. 245 RFC 1510bis specifies the ASN.1 structure for PrincipalName as follows: 247 PrincipalName ::= SEQUENCE { 248 name-type[0] INTEGER, 249 name-string[1] SEQUENCE OF GeneralString 250 } 252 The following rules relate to the the matching of PrincipalNames 253 with regard to the PKI name constraints for CAs as laid out in RFC 254 2459 [12]. In order to be regarded as a match (for permitted and 255 excluded name trees), the following MUST be satisfied. 257 1. If the constraint is given as a user plus realm name, or 258 as a client principal name plus realm name (as specified in 259 RFC 1510bis), the realm name MUST be valid (see 2.a-d below) 260 and the match MUST be exact, byte for byte. 262 2. If the constraint is given only as a realm name, matching 263 depends on the type of the realm: 265 a. If the realm contains a colon (':') before any equal 266 sign ('='), it is treated as a realm of type Other, 267 and MUST match exactly, byte for byte. 269 b. Otherwise, if the realm name conforms to rules regarding 270 the format of DNS names, it is considered a realm name of 271 type Domain. The constraint may be given as a realm 272 name 'FOO.BAR', which matches any PrincipalName within 273 the realm 'FOO.BAR' but not those in subrealms such as 274 'CAR.FOO.BAR'. A constraint of the form '.FOO.BAR' 275 matches PrincipalNames in subrealms of the form 276 'CAR.FOO.BAR' but not the realm 'FOO.BAR' itself. 278 c. Otherwise, the realm name is invalid and does not match 279 under any conditions. 281 3.1.1. Encryption and Key Formats 283 In the exposition below, we use the terms public key and private 284 key generically. It should be understood that the term "public 285 key" may be used to refer to either a public encryption key or a 286 signature verification key, and that the term "private key" may be 287 used to refer to either a private decryption key or a signature 288 generation key. The fact that these are logically distinct does 289 not preclude the assignment of bitwise identical keys for RSA 290 keys. 292 In the case of Diffie-Hellman, the key is produced from the agreed 293 bit string as follows: 295 * Truncate the bit string to the required length. 296 * Apply the specific cryptosystem's random-to-key function. 298 Appropriate key constraints for each valid cryptosystem are given 299 in RFC 1510bis. 301 3.1.2. Algorithm Identifiers 303 PKINIT does not define, but does permit, the algorithm identifiers 304 listed below. 306 3.1.2.1. Signature Algorithm Identifiers 308 The following signature algorithm identifiers specified in [8] and 309 in [12] are used with PKINIT: 311 sha-1WithRSAEncryption (RSA with SHA1) 312 md5WithRSAEncryption (RSA with MD5) 313 id-dsa-with-sha1 (DSA with SHA1) 315 3.1.2.2 Diffie-Hellman Key Agreement Algorithm Identifier 317 The following algorithm identifier shall be used within the 318 SubjectPublicKeyInfo data structure: dhpublicnumber 320 This identifier and the associated algorithm parameters are 321 specified in RFC 2459 [12]. 323 3.1.2.3. Algorithm Identifiers for RSA Encryption 325 These algorithm identifiers are used inside the EnvelopedData data 326 structure, for encrypting the temporary key with a public key: 328 rsaEncryption (RSA encryption, PKCS#1 v1.5) 329 id-RSAES-OAEP (RSA encryption, PKCS#1 v2.0) 331 Both of the above RSA encryption schemes are specified in [13]. 332 Currently, only PKCS#1 v1.5 is specified by CMS [8], although the 333 CMS specification says that it will likely include PKCS#1 v2.0 in 334 the future. (PKCS#1 v2.0 addresses adaptive chosen ciphertext 335 vulnerability discovered in PKCS#1 v1.5.) 337 3.1.2.4. Algorithm Identifiers for Encryption with Secret Keys 339 These algorithm identifiers are used inside the EnvelopedData data 340 structure in the PKINIT Reply, for encrypting the reply key with the 341 temporary key: 342 des-ede3-cbc (3-key 3-DES, CBC mode) 343 rc2-cbc (RC2, CBC mode) 345 The full definition of the above algorithm identifiers and their 346 corresponding parameters (an IV for block chaining) is provided in 347 the CMS specification [8]. 349 3.2. Public Key Authentication 351 Implementation of the changes in this section is REQUIRED for 352 compliance with PKINIT. 354 3.2.1. Client Request 356 Public keys may be signed by some certification authority (CA), or 357 they may be maintained by the KDC in which case the KDC is the 358 trusted authority. Note that the latter mode does not require the 359 use of certificates. 361 The initial authentication request is sent as per RFC 1510bis, except 362 that a preauthentication field containing data signed by the user's 363 private key accompanies the request: 365 PA-PK-AS-REQ ::= SEQUENCE { 366 -- PA TYPE 14 367 signedAuthPack [0] ContentInfo, 368 -- Defined in CMS [8]; 369 -- SignedData OID is {pkcs7 2} 370 -- AuthPack (below) defines the 371 -- data that is signed. 372 trustedCertifiers [1] SEQUENCE OF TrustedCas OPTIONAL, 373 -- This is a list of CAs that the 374 -- client trusts and that certify 375 -- KDCs. 376 kdcCert [2] IssuerAndSerialNumber OPTIONAL 377 -- As defined in CMS [8]; 378 -- specifies a particular KDC 379 -- certificate if the client 380 -- already has it. 381 encryptionCert [3] IssuerAndSerialNumber OPTIONAL 382 -- For example, this may be the 383 -- client's Diffie-Hellman 384 -- certificate, or it may be the 385 -- client's RSA encryption 386 -- certificate. 387 } 389 TrustedCas ::= CHOICE { 390 principalName [0] KerberosName, 391 -- as defined below 392 caName [1] Name 393 -- fully qualified X.500 name 394 -- as defined by X.509 395 issuerAndSerial [2] IssuerAndSerialNumber 396 -- Since a CA may have a number of 397 -- certificates, only one of which 398 -- a client trusts 399 } 401 The type of the ContentInfo in the signedAuthPack is SignedData. 402 Its usage is as follows: 404 The SignedData data type is specified in the Cryptographic 405 Message Syntax, a product of the S/MIME working group of the 406 IETF. The following describes how to fill in the fields of 407 this data: 409 1. The encapContentInfo field MUST contain the PKAuthenticator 410 and, optionally, the client's Diffie Hellman public value. 412 a. The eContentType field MUST contain the OID value for 413 pkauthdata: iso (1) org (3) dod (6) internet (1) 414 security (5) kerberosv5 (2) pkinit (3) pkauthdata (1) 416 b. The eContent field is data of the type AuthPack (below). 418 2. The signerInfos field contains the signature of AuthPack. 420 3. The Certificates field, when non-empty, contains the client's 421 certificate chain. If present, the KDC uses the public key 422 from the client's certificate to verify the signature in the 423 request. Note that the client may pass different certificate 424 chains that are used for signing or for encrypting. Thus, 425 the KDC may utilize a different client certificate for 426 signature verification than the one it uses to encrypt the 427 reply to the client. For example, the client may place a 428 Diffie-Hellman certificate in this field in order to convey 429 its static Diffie Hellman certificate to the KDC to enable 430 static-ephemeral Diffie-Hellman mode for the reply; in this 431 case, the client does NOT place its public value in the 432 AuthPack (defined below). As another example, the client may 433 place an RSA encryption certificate in this field. However, 434 there MUST always be (at least) a signature certificate. 436 4. When a DH key is being used, the public exponent is provided 437 in the subjectPublicKey field of the SubjectPublicKeyInfo and 438 the DH parameters are supplied as a DomainParameters in the 439 AlgorithmIdentitfier parameters. The DH paramters SHOULD be 440 chosen from the First and Second defined Oakley Groups [The 441 Internet Key Exchange (IKE) RFC-2409], if a server will not 442 accept either of these groups, it will respond with a krb- 443 error of KDC_ERR_KEY_TOO_WEAK. The accompanying e-data is 444 a SEQUENCE of TypedData that includes type 445 TD-DH-PARAMETERS (102) whose data-value is DomainParameters 446 with appropriate Diffie-Hellman parameters for the client to 447 use. 449 5. The KDC may wish to use cached Diffie-Hellman parameters 450 (see Section 3.2.2, KDC Response). To indicate acceptance 451 of cached parameters, the client sends zero in the nonce 452 field of the PKAuthenticator. Zero is not a valid value 453 for this field under any other circumstances. If cached 454 parameters are used, the client and the KDC MUST perform 455 key derivation (for the appropriate cryptosystem) on the 456 resulting encryption key, as specified in RFC 1510bis. (With 457 a zero nonce, message binding is performed using the nonce 458 in the main request, which must be encrypted using the 459 encapsulated reply key.) 461 AuthPack ::= SEQUENCE { 462 pkAuthenticator [0] PKAuthenticator, 463 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL 464 -- if client is using Diffie-Hellman 465 -- (ephemeral-ephemeral only) 466 } 468 PKAuthenticator ::= SEQUENCE { 469 cusec [0] INTEGER, 470 -- for replay prevention as in RFC 1510bis 471 ctime [1] KerberosTime, 472 -- for replay prevention as in RFC 1510bis 473 nonce [2] INTEGER, 474 -- zero only if client will accept 475 -- cached DH parameters from KDC; 476 -- must be non-zero otherwise 477 pachecksum [3] Checksum 478 -- Checksum over KDC-REQ-BODY 479 -- Defined by Kerberos spec; 480 -- must be unkeyed, e.g. sha1 or rsa-md5 481 } 483 SubjectPublicKeyInfo ::= SEQUENCE { 484 algorithm AlgorithmIdentifier, 485 -- dhPublicNumber 486 subjectPublicKey BIT STRING 487 -- for DH, equals 488 -- public exponent (INTEGER encoded 489 -- as payload of BIT STRING) 490 } -- as specified by the X.509 recommendation [7] 492 AlgorithmIdentifier ::= SEQUENCE { 493 algorithm OBJECT IDENTIFIER, 494 -- for dhPublicNumber, this is 495 -- { iso (1) member-body (2) US (840) 496 -- ansi-x942(10046) number-type(2) 1 } 497 -- from RFC 2459 [12] 498 parameters ANY DEFINED by algorithm OPTIONAL 499 -- for dhPublicNumber, this is 500 -- DomainParameters 501 } -- as specified by the X.509 recommendation [7] 503 DomainParameters ::= SEQUENCE { 504 p INTEGER, -- odd prime, p=jq +1 505 g INTEGER, -- generator, g 506 q INTEGER, -- factor of p-1 507 j INTEGER OPTIONAL, -- subgroup factor 508 validationParms ValidationParms OPTIONAL 509 } -- as defined in RFC 2459 [12] 511 ValidationParms ::= SEQUENCE { 512 seed BIT STRING, 513 -- seed for the system parameter 514 -- generation process 515 pgenCounter INTEGER 516 -- integer value output as part 517 -- of the of the system parameter 518 -- prime generation process 519 } -- as defined in RFC 2459 [12] 521 If the client passes an issuer and serial number in the request, 522 the KDC is requested to use the referred-to certificate. If none 523 exists, then the KDC returns an error of type 524 KDC_ERR_CERTIFICATE_MISMATCH. It also returns this error if, on the 525 other hand, the client does not pass any trustedCertifiers, 526 believing that it has the KDC's certificate, but the KDC has more 527 than one certificate. The KDC should include information in the 528 KRB-ERROR message that indicates the KDC certificate(s) that a 529 client may utilize. This data is specified in the e-data, which 530 is defined in RFC 1510bis revisions as a SEQUENCE of TypedData: 532 TypedData ::= SEQUENCE { 533 data-type [0] INTEGER, 534 data-value [1] OCTET STRING, 535 } -- per Kerberos RFC 1510bis 537 where one of the TypedData elements is: 538 data-type = TD-PKINIT-CMS-CERTIFICATES = 101 539 data-value = CertificateSet // as specified by CMS [8] 541 The PKAuthenticator carries information to foil replay attacks, to 542 bind the pre-authentication data to the KDC-REQ-BODY, and to bind the 543 request and response. The PKAuthenticator is signed with the client's 544 signature key. 546 3.2.2. KDC Response 548 Upon receipt of the AS_REQ with PA-PK-AS-REQ pre-authentication 549 type, the KDC attempts to verify the client's certificate chain, if 550 one is provided in the request. This is done by verifying the 551 certification path against the KDC's policy of legitimate 552 certifiers. 554 If the KDC cannot find a trusted client certificate chain within 555 the PA-PK-AS-REQ, then the KDC sends back an error message of type 556 KDC_ERR_CANT_VERIFY_CERTIFICATE. Certificate chain validation is 557 defined in RFC 2459 [12]. The accompanying e-data for this error 558 code is a SEQUENCE of TypedData that includes type 559 TD-TRUSTED-CERTIFIERS (104) whose data-value is an OCTET STRING 560 which is the DER encoding of 562 TrustedCertifiers ::= SEQUENCE OF PrincipalName 563 -- X.500 name encoded as a principal name 564 -- see Section 3.1 566 If while verifying a certificate chain the KDC determines that the 567 signature on one of the certificates in the CertificateSet from 568 the signedAuthPack fails verification, then the KDC returns an 569 error of type KDC_ERR_INVALID_CERTIFICATE. The accompanying 570 e-data is a SEQUENCE of TypedData that includes type 571 TD-CERTIFICATE-INDEX (105) whose data-value is an OCTET STRING 572 which is the DER encoding of the index into the CertificateSet 573 ordered as sent by the client. 575 CertificateIndex ::= INTEGER 576 -- 0 = 1st certificate, 577 -- (in order of encoding) 578 -- 1 = 2nd certificate, etc 580 The KDC may also check whether any of the certificates in the 581 client's chain has been revoked. If one of the certificates has 582 been revoked, then the KDC returns an error of type 583 KDC_ERR_REVOKED_CERTIFICATE; if such a query reveals that 584 the certificate's revocation status is unknown or not 585 available, then if required by policy, the KDC returns the 586 appropriate error of type KDC_ERR_REVOCATION_STATUS_UNKNOWN or 587 KDC_ERR_REVOCATION_STATUS_UNAVAILABLE. In any of these three 588 cases, the affected certificate is identified by the accompanying 589 e-data, which contains a CertificateIndex as described for 590 KDC_ERR_INVALID_CERTIFICATE. 592 If the certificate chain can be verified, but the name of the 593 client in the certificate does not match the client's name in the 594 request, then the KDC returns an error of type 595 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data 596 field in this case. 598 Even if all succeeds, the KDC may--for policy reasons--decide not 599 to trust the client. In this case, the KDC returns an error message 600 of type KDC_ERR_CLIENT_NOT_TRUSTED. One specific case of this is 601 the presence or absence of an Enhanced Key Usage (EKU) OID within 602 the certificate extensions. The rules regarding acceptability of 603 an EKU sequence (or the absence of any sequence) are a matter of 604 local policy. For the benefit of implementers, we define a PKINIT 605 EKU OID as the following: iso (1) org (3) dod (6) internet (1) 606 security (5) kerberosv5 (2) pkinit (3) pkekuoid (2). 608 If a trust relationship exists, the KDC then verifies the client's 609 signature on AuthPack. If that fails, the KDC returns an error 610 message of type KDC_ERR_INVALID_SIG. Otherwise, the KDC uses the 611 timestamp (ctime and cusec) in the PKAuthenticator to assure that 612 the request is not a replay. The KDC also verifies that its name 613 is specified in the PKAuthenticator. 615 If the clientPublicValue field is filled in, indicating that the 616 client wishes to use Diffie-Hellman key agreement, then the KDC 617 checks to see that the parameters satisfy its policy. If they do 618 not (e.g., the prime size is insufficient for the expected 619 encryption type), then the KDC sends back an error message of type 620 KDC_ERR_KEY_TOO_WEAK. The accompanying e-data is a SEQUENCE of 621 TypedData that includes type TD-DH-PARAMETERS (102) whose data-value 622 is DomainParameters with appropriate Diffie-Hellman parameters for 623 the client to retry the request. Otherwise, it generates its own 624 public and private values for the response. 626 The KDC also checks that the timestamp in the PKAuthenticator is 627 within the allowable window and that the principal name and realm 628 are correct. If the local (server) time and the client time in the 629 authenticator differ by more than the allowable clock skew, then the 630 KDC returns an error message of type KRB_AP_ERR_SKEW as defined in 631 RFC 1510bis. 633 Assuming no errors, the KDC replies as per RFC 1510bis, except as 634 follows. The user's name in the ticket is determined by the 635 following decision algorithm: 637 1. If the KDC has a mapping from the name in the certificate 638 to a Kerberos name, then use that name. 639 Else 640 2. If the certificate contains the SubjectAltName extention 641 and the local KDC policy defines a mapping from the 642 SubjectAltName to a Kerberos name, then use that name. 643 Else 644 3. Use the name as represented in the certificate, mapping 645 as necessary (e.g., as per RFC 2253 for X.500 names). In 646 this case the realm in the ticket MUST be the name of the 647 certifier that issued the user's certificate. 649 Note that a principal name may be carried in the subjectAltName 650 field of a certificate. This name may be mapped to a principal 651 record in a security database based on local policy, for example 652 the subjectAltName may be kerberos/principal@realm format. In 653 this case the realm name is not that of the CA but that of the 654 local realm doing the mapping (or some realm name chosen by that 655 realm). 657 If a non-KDC X.509 certificate contains the principal name within 658 the subjectAltName version 3 extension, that name may utilize 659 KerberosName as defined below, or, in the case of an S/MIME 660 certificate [14], may utilize the email address. If the KDC 661 is presented with an S/MIME certificate, then the email address 662 within subjectAltName will be interpreted as a principal and realm 663 separated by the "@" sign, or as a name that needs to be mapped 664 according to local policy. If the resulting name does not correspond 665 to a registered principal name, then the principal name is formed as 666 defined in section 3.1. 668 The trustedCertifiers field contains a list of certification 669 authorities trusted by the client, in the case that the client does 670 not possess the KDC's public key certificate. If the KDC has no 671 certificate signed by any of the trustedCertifiers, then it returns 672 an error of type KDC_ERR_KDC_NOT_TRUSTED. 674 KDCs should try to (in order of preference): 675 1. Use the KDC certificate identified by the serialNumber included 676 in the client's request. 677 2. Use a certificate issued to the KDC by one of the client's 678 trustedCertifier(s); 679 If the KDC is unable to comply with any of these options, then the 680 KDC returns an error message of type KDC_ERR_KDC_NOT_TRUSTED to the 681 client. 683 The KDC encrypts the reply not with the user's long-term key, but 684 with the Diffie Hellman derived key or a random key generated 685 for this particular response which is carried in the padata field of 686 the TGS-REP message. 688 PA-PK-AS-REP ::= CHOICE { 689 -- PA TYPE 15 690 dhSignedData [0] ContentInfo, 691 -- Defined in CMS [8] and used only with 692 -- Diffie-Hellman key exchange (if the 693 -- client public value was present in the 694 -- request). 695 -- SignedData OID is {pkcs7 2} 696 -- This choice MUST be supported 697 -- by compliant implementations. 698 encKeyPack [1] ContentInfo 699 -- Defined in CMS [8]. 700 -- The temporary key is encrypted 701 -- using the client public key 702 -- key. 703 -- EnvelopedData OID is {pkcs7 3} 704 -- SignedReplyKeyPack, encrypted 705 -- with the temporary key, is also 706 -- included. 707 } 709 The type of the ContentInfo in the dhSignedData is SignedData. 710 Its usage is as follows: 712 When the Diffie-Hellman option is used, dhSignedData in 713 PA-PK-AS-REP provides authenticated Diffie-Hellman parameters 714 of the KDC. The reply key used to encrypt part of the KDC reply 715 message is derived from the Diffie-Hellman exchange: 717 1. Both the KDC and the client calculate a secret value 718 (g^ab mod p), where a is the client's private exponent and 719 b is the KDC's private exponent. 721 2. Both the KDC and the client take the first N bits of this 722 secret value and convert it into a reply key. N depends on 723 the reply key type. 725 a. For example, if the reply key is DES, N=64 bits, where 726 some of the bits are replaced with parity bits, according 727 to FIPS PUB 74. 729 b. As another example, if the reply key is (3-key) 3-DES, 730 N=192 bits, where some of the bits are replaced with 731 parity bits, according to FIPS PUB 74. 733 3. The encapContentInfo field MUST contain the KdcDHKeyInfo as 734 defined below. 736 a. The eContentType field MUST contain the OID value for 737 pkdhkeydata: iso (1) org (3) dod (6) internet (1) 738 security (5) kerberosv5 (2) pkinit (3) pkdhkeydata (2) 740 b. The eContent field is data of the type KdcDHKeyInfo 741 (below). 743 4. The certificates field MUST contain the certificates 744 necessary for the client to establish trust in the KDC's 745 certificate based on the list of trusted certifiers sent by 746 the client in the PA-PK-AS-REQ. This field may be empty if 747 the client did not send to the KDC a list of trusted 748 certifiers (the trustedCertifiers field was empty, meaning 749 that the client already possesses the KDC's certificate). 751 5. The signerInfos field is a SET that MUST contain at least 752 one member, since it contains the actual signature. 754 6. If the client indicated acceptance of cached Diffie-Hellman 755 parameters from the KDC, and the KDC supports such an option 756 (for performance reasons), the KDC should return a zero in 757 the nonce field and include the expiration time of the 758 parameters in the dhKeyExpiration field. If this time is 759 exceeded, the client SHOULD NOT use the reply. If the time 760 is absent, the client SHOULD NOT use the reply and MAY 761 resubmit a request with a non-zero nonce (thus indicating 762 non-acceptance of cached Diffie-Hellman parameters). As 763 indicated above in Section 3.2.1, Client Request, when the 764 KDC uses cached parameters, the client and the KDC MUST 765 perform key derivation (for the appropriate cryptosystem) 766 on the resulting encryption key, as specified in RFC 1510bis. 768 KdcDHKeyInfo ::= SEQUENCE { 769 -- used only when utilizing Diffie-Hellman 770 subjectPublicKey [0] BIT STRING, 771 -- Equals public exponent (g^a mod p) 772 -- INTEGER encoded as payload of 773 -- BIT STRING 774 nonce [1] INTEGER, 775 -- Binds response to the request 776 -- Exception: Set to zero when KDC 777 -- is using a cached DH value 778 dhKeyExpiration [2] KerberosTime OPTIONAL 779 -- Expiration time for KDC's cached 780 -- DH value 781 } 783 The type of the ContentInfo in the encKeyPack is EnvelopedData. Its 784 usage is as follows: 786 The EnvelopedData data type is specified in the Cryptographic 787 Message Syntax, a product of the S/MIME working group of the 788 IETF. It contains a temporary key encrypted with the PKINIT 789 client's public key. It also contains a signed and encrypted 790 reply key. 792 1. The originatorInfo field is not required, since that 793 information may be presented in the signedData structure 794 that is encrypted within the encryptedContentInfo field. 796 2. The optional unprotectedAttrs field is not required for 797 PKINIT. 799 3. The recipientInfos field is a SET which MUST contain exactly 800 one member of the KeyTransRecipientInfo type for encryption 801 with a public key. 803 a. The encryptedKey field (in KeyTransRecipientInfo) 804 contains the temporary key which is encrypted with the 805 PKINIT client's public key. 807 4. The encryptedContentInfo field contains the signed and 808 encrypted reply key. 810 a. The contentType field MUST contain the OID value for 811 id-signedData: iso (1) member-body (2) us (840) 812 rsadsi (113549) pkcs (1) pkcs7 (7) signedData (2) 814 b. The encryptedContent field is encrypted data of the CMS 815 type signedData as specified below. 817 i. The encapContentInfo field MUST contains the 818 ReplyKeyPack. 820 * The eContentType field MUST contain the OID value 821 for pkrkeydata: iso (1) org (3) dod (6) internet (1) 822 security (5) kerberosv5 (2) pkinit (3) pkrkeydata (3) 824 * The eContent field is data of the type ReplyKeyPack 825 (below). 827 ii. The certificates field MUST contain the certificates 828 necessary for the client to establish trust in the 829 KDC's certificate based on the list of trusted 830 certifiers sent by the client in the PA-PK-AS-REQ. 831 This field may be empty if the client did not send 832 to the KDC a list of trusted certifiers (the 833 trustedCertifiers field was empty, meaning that the 834 client already possesses the KDC's certificate). 836 iii. The signerInfos field is a SET that MUST contain at 837 least one member, since it contains the actual 838 signature. 840 ReplyKeyPack ::= SEQUENCE { 841 -- not used for Diffie-Hellman 842 replyKey [0] EncryptionKey, 843 -- from RFC 1510bis 844 -- used to encrypt main reply 845 -- ENCTYPE is at least as strong as 846 -- ENCTYPE of session key 847 nonce [1] INTEGER, 848 -- binds response to the request 849 -- must be same as the nonce 850 -- passed in the PKAuthenticator 851 } 853 3.2.2.1. Use of transited Field 855 Since each certifier in the certification path of a user's 856 certificate is equivalent to a separate Kerberos realm, the name 857 of each certifier in the certificate chain MUST be added to the 858 transited field of the ticket. The format of these realm names is 859 defined in Section 3.1 of this document. If applicable, the 860 transit-policy-checked flag should be set in the issued ticket. 862 3.2.2.2. Kerberos Names in Certificates 864 The KDC's certificate(s) MUST bind the public key(s) of the KDC to 865 a name derivable from the name of the realm for that KDC. X.509 866 certificates MUST contain the principal name of the KDC (defined in 867 RFC 1510bis) as the SubjectAltName version 3 extension. Below is 868 the definition of this version 3 extension, as specified by the 869 X.509 standard: 871 subjectAltName EXTENSION ::= { 872 SYNTAX GeneralNames 873 IDENTIFIED BY id-ce-subjectAltName 874 } 876 GeneralNames ::= SEQUENCE SIZE(1..MAX) OF GeneralName 878 GeneralName ::= CHOICE { 879 otherName [0] OtherName, 880 ... 881 } 883 OtherName ::= SEQUENCE { 884 type-id OBJECT IDENTIFIER, 885 value [0] EXPLICIT ANY DEFINED BY type-id 886 } 888 For the purpose of specifying a Kerberos principal name, the value 889 in OtherName MUST be a KerberosName, defined as follows: 891 KerberosName ::= SEQUENCE { 892 realm [0] Realm, 893 principalName [1] PrincipalName 894 } 896 This specific syntax is identified within subjectAltName by setting 897 the type-id in OtherName to krb5PrincipalName, where (from the 898 Kerberos specification) we have 900 krb5 OBJECT IDENTIFIER ::= { iso (1) 901 org (3) 902 dod (6) 903 internet (1) 904 security (5) 905 kerberosv5 (2) } 907 krb5PrincipalName OBJECT IDENTIFIER ::= { krb5 2 } 909 (This specification may also be used to specify a Kerberos name 910 within the user's certificate.) The KDC's certificate may be signed 911 directly by a CA, or there may be intermediaries if the server resides 912 within a large organization, or it may be unsigned if the client 913 indicates possession (and trust) of the KDC's certificate. 915 Note that the KDC's principal name has the instance equal to the 916 realm, and those fields should be appropriately set in the realm 917 and principalName fields of the KerberosName. This is the case 918 even when obtaining a cross-realm ticket using PKINIT. 920 3.2.3. Client Extraction of Reply 922 The client then extracts the random key used to encrypt the main 923 reply. This random key (in encPaReply) is encrypted with either the 924 client's public key or with a key derived from the DH values 925 exchanged between the client and the KDC. The client uses this 926 random key to decrypt the main reply, and subsequently proceeds as 927 described in RFC 1510bis. 929 3.2.4. Required Algorithms 931 Not all of the algorithms in the PKINIT protocol specification have 932 to be implemented in order to comply with the proposed standard. 933 Below is a list of the required algorithms: 935 * Diffie-Hellman public/private key pairs 936 * utilizing Diffie-Hellman ephemeral-ephemeral mode 937 * SHA1 digest and RSA for signatures 938 * SHA1 digest for the Checksum in the PKAuthenticator 939 * using Kerberos checksum type 'sha1' 940 * 3-key triple DES keys derived from the Diffie-Hellman Exchange 941 * 3-key triple DES Temporary and Reply keys 943 4. Logistics and Policy 945 This section describes a way to define the policy on the use of 946 PKINIT for each principal and request. 948 The KDC is not required to contain a database record for users 949 who use public key authentication. However, if these users are 950 registered with the KDC, it is recommended that the database record 951 for these users be modified to an additional flag in the attributes 952 field to indicate that the user should authenticate using PKINIT. 953 If this flag is set and a request message does not contain the 954 PKINIT preauthentication field, then the KDC sends back as error of 955 type KDC_ERR_PREAUTH_REQUIRED indicating that a preauthentication 956 field of type PA-PK-AS-REQ must be included in the request. 958 5. Security Considerations 960 PKINIT raises a few security considerations, which we will address 961 in this section. 963 First of all, PKINIT extends the cross-realm model to the public 964 key infrastructure. Anyone using PKINIT must be aware of how the 965 certification infrastructure they are linking to works. 967 Also, as in standard Kerberos, PKINIT presents the possibility of 968 interactions between different cryptosystems of varying strengths, 969 and this now includes public-key cryptosystems. Many systems, for 970 instance, allow the use of 512-bit public keys. Using such keys 971 to wrap data encrypted under strong conventional cryptosystems, 972 such as triple-DES, may be inappropriate. 974 Care should be taken in how certificates are choosen for the purposes 975 of authentication using PKINIT. Some local policies require that key 976 escrow be applied for certain certificate types. People deploying 977 PKINIT should be aware of the implications of using certificates that 978 have escrowed keys for the purposes of authentication. 980 As described in Section 3.2, PKINIT allows for the caching of the 981 Diffie-Hellman parameters on the KDC side, for performance reasons. 982 For similar reasons, the signed data in this case does not vary from 983 message to message, until the cached parameters expire. Because of 984 the persistence of these parameters, the client and the KDC are to 985 use the appropriate key derivation measures (as described in RFC 986 1510bis) when using cached DH parameters. 988 PKINIT does not provide for a "return routability test" to prevent 989 attackers from mounting a denial of service attack on the KDC by 990 causing it to perform needless expensive cryptographic operations. 991 Strictly speaking, this is also true of base Kerberos, although the 992 potential cost is not as great in base Kerberos, because it does 993 not make use of public key cryptography. 995 Lastly, PKINIT calls for randomly generated keys for conventional 996 cryptosystems. Many such systems contain systematically "weak" 997 keys. For recommendations regarding these weak keys, see RFC 998 1510bis. 1000 6. Transport Issues 1002 Certificate chains can potentially grow quite large and span several 1003 UDP packets; this in turn increases the probability that a Kerberos 1004 message involving PKINIT extensions will be broken in transit. In 1005 light of the possibility that the Kerberos specification will 1006 require KDCs to accept requests using TCP as a transport mechanism, 1007 we make the same recommendation with respect to the PKINIT 1008 extensions as well. 1010 7. Bibliography 1012 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication Service 1013 (V5). Request for Comments 1510. 1015 [2] B.C. Neuman, Theodore Ts'o. Kerberos: An Authentication Service 1016 for Computer Networks, IEEE Communications, 32(9):33-38. September 1017 1994. 1019 [3] M. Sirbu, J. Chuang. Distributed Authentication in Kerberos 1020 Using Public Key Cryptography. Symposium On Network and Distributed 1021 System Security, 1997. 1023 [4] B. Cox, J.D. Tygar, M. Sirbu. NetBill Security and Transaction 1024 Protocol. In Proceedings of the USENIX Workshop on Electronic 1025 Commerce, July 1995. 1027 [5] T. Dierks, C. Allen. The TLS Protocol, Version 1.0 1028 Request for Comments 2246, January 1999. 1030 [6] B.C. Neuman, Proxy-Based Authorization and Accounting for 1031 Distributed Systems. In Proceedings of the 13th International 1032 Conference on Distributed Computing Systems, May 1993. 1034 [7] ITU-T (formerly CCITT) Information technology - Open Systems 1035 Interconnection - The Directory: Authentication Framework 1036 Recommendation X.509 ISO/IEC 9594-8 1038 [8] R. Housley. Cryptographic Message Syntax. 1039 draft-ietf-smime-cms-13.txt, April 1999, approved for publication 1040 as RFC. 1042 [9] PKCS #7: Cryptographic Message Syntax Standard, 1043 An RSA Laboratories Technical Note Version 1.5 1044 Revised November 1, 1993 1046 [10] R. Rivest, MIT Laboratory for Computer Science and RSA Data 1047 Security, Inc. A Description of the RC2(r) Encryption Algorithm 1048 March 1998. 1049 Request for Comments 2268. 1051 [11] M. Wahl, S. Kille, T. Howes. Lightweight Directory Access 1052 Protocol (v3): UTF-8 String Representation of Distinguished Names. 1053 Request for Comments 2253. 1055 [12] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public 1056 Key Infrastructure, Certificate and CRL Profile, January 1999. 1057 Request for Comments 2459. 1059 [13] B. Kaliski, J. Staddon. PKCS #1: RSA Cryptography 1060 Specifications, October 1998. Request for Comments 2437. 1062 [14] S. Dusse, P. Hoffman, B. Ramsdell, J. Weinstein. S/MIME 1063 Version 2 Certificate Handling, March 1998. Request for 1064 Comments 2312. 1066 [15] M. Wahl, T. Howes, S. Kille. Lightweight Directory Access 1067 Protocol (v3), December 1997. Request for Comments 2251. 1069 [16] ITU-T (formerly CCITT) Information Processing Systems - Open 1070 Systems Interconnection - Specification of Abstract Syntax Notation 1071 One (ASN.1) Rec. X.680 ISO/IEC 8824-1 1073 [17] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA 1074 Laboratories Technical Note, Version 1.4, Revised November 1, 1993. 1076 8. Acknowledgements 1078 Some of the ideas on which this proposal is based arose during 1079 discussions over several years between members of the SAAG, the IETF 1080 CAT working group, and the PSRG, regarding integration of Kerberos 1081 and SPX. Some ideas have also been drawn from the DASS system. 1082 These changes are by no means endorsed by these groups. This is an 1083 attempt to revive some of the goals of those groups, and this 1084 proposal approaches those goals primarily from the Kerberos 1085 perspective. Lastly, comments from groups working on similar ideas 1086 in DCE have been invaluable. 1088 9. Expiration Date 1090 This draft expires March 12, 2002. 1092 10. Authors 1094 Brian Tung 1095 Clifford Neuman 1096 USC Information Sciences Institute 1097 4676 Admiralty Way Suite 1001 1098 Marina del Rey CA 90292-6695 1099 Phone: +1 310 822 1511 1100 E-mail: {brian, bcn}@isi.edu 1102 Matthew Hur 1103 Microsoft Corporation 1104 One Microsoft Way 1105 Redmond WA 98052 1106 Phone: +1 425 707 3336 1107 E-mail: matthur@microsoft.com 1109 Ari Medvinsky 1110 Liberate Technologies 1111 2 Circle Star Way 1112 San Carlos CA 94070 1113 E-mail: ari@liberate.com 1115 Sasha Medvinsky 1116 Motorola, Inc. 1117 6450 Sequence Drive 1118 San Diego, CA 92121 1119 +1 858 404 2367 1120 E-mail: smedvinsky@gi.com 1122 John Wray 1123 Iris Associates, Inc. 1124 5 Technology Park Dr. 1125 Westford, MA 01886 1126 E-mail: John_Wray@iris.com 1128 Jonathan Trostle 1129 E-mail: jtrostle@world.std.com