1 NETWORK WORKING GROUP B. Tung
2 Internet-Draft USC Information Sciences Institute
3 Expires: April 22, 2006 L. Zhu
8 Public Key Cryptography for Initial Authentication in Kerberos
9 draft-ietf-cat-kerberos-pk-init-29
13 By submitting this Internet-Draft, each author represents that any
14 applicable patent or other IPR claims of which he or she is aware
15 have been or will be disclosed, and any of which he or she becomes
16 aware will be disclosed, in accordance with Section 6 of BCP 79.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as Internet-
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt.
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 This Internet-Draft will expire on April 22, 2006.
38 Copyright (C) The Internet Society (2005).
42 This document describes protocol extensions (hereafter called PKINIT)
43 to the Kerberos protocol specification. These extensions provide a
44 method for integrating public key cryptography into the initial
45 authentication exchange, by using asymmetric-key signature and/or
46 encryption algorithms in pre-authentication data fields.
52 Tung & Zhu Expires April 22, 2006 [Page 1]
54 Internet-Draft PKINIT October 2005
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
60 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
61 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
62 3.1. Definitions, Requirements, and Constants . . . . . . . . . 4
63 3.1.1. Required Algorithms . . . . . . . . . . . . . . . . . 4
64 3.1.2. Defined Message and Encryption Types . . . . . . . . . 5
65 3.1.3. Algorithm Identifiers . . . . . . . . . . . . . . . . 6
66 3.2. PKINIT Pre-authentication Syntax and Use . . . . . . . . . 7
67 3.2.1. Generation of Client Request . . . . . . . . . . . . . 7
68 3.2.2. Receipt of Client Request . . . . . . . . . . . . . . 10
69 3.2.3. Generation of KDC Reply . . . . . . . . . . . . . . . 14
70 3.2.4. Receipt of KDC Reply . . . . . . . . . . . . . . . . . 20
71 3.3. Interoperability Requirements . . . . . . . . . . . . . . 21
72 3.4. KDC Indication of PKINIT Support . . . . . . . . . . . . . 21
73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22
74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
77 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25
78 7.2. Informative References . . . . . . . . . . . . . . . . . . 26
79 Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 26
80 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 32
81 Appendix C. Miscellaneous Information about Microsoft Windows
82 PKINIT Implementations . . . . . . . . . . . . . . . 33
83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
84 Intellectual Property and Copyright Statements . . . . . . . . . . 36
108 Tung & Zhu Expires April 22, 2006 [Page 2]
110 Internet-Draft PKINIT October 2005
115 A client typically authenticates itself to a service in Kerberos
116 using three distinct though related exchanges. First, the client
117 requests a ticket-granting ticket (TGT) from the Kerberos
118 authentication server (AS). Then, it uses the TGT to request a
119 service ticket from the Kerberos ticket-granting server (TGS).
120 Usually, the AS and TGS are integrated in a single device known as a
121 Kerberos Key Distribution Center, or KDC. Finally, the client uses
122 the service ticket to authenticate itself to the service.
124 The advantage afforded by the TGT is that the client exposes his
125 long-term secrets only once. The TGT and its associated session key
126 can then be used for any subsequent service ticket requests. One
127 result of this is that all further authentication is independent of
128 the method by which the initial authentication was performed.
129 Consequently, initial authentication provides a convenient place to
130 integrate public-key cryptography into Kerberos authentication.
132 As defined in [RFC4120], Kerberos authentication exchanges use
133 symmetric-key cryptography, in part for performance. One
134 disadvantage of using symmetric-key cryptography is that the keys
135 must be shared, so that before a client can authenticate itself, he
136 must already be registered with the KDC.
138 Conversely, public-key cryptography (in conjunction with an
139 established Public Key Infrastructure) permits authentication without
140 prior registration with a KDC. Adding it to Kerberos allows the
141 widespread use of Kerberized applications by clients without
142 requiring them to register first with a KDC--a requirement that has
143 no inherent security benefit.
145 As noted above, a convenient and efficient place to introduce public-
146 key cryptography into Kerberos is in the initial authentication
147 exchange. This document describes the methods and data formats for
148 integrating public-key cryptography into Kerberos initial
152 2. Conventions Used in This Document
154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
156 document are to be interpreted as described in [RFC2119].
158 Both the AS and the TGS are referred to as the KDC.
160 In this document, the encryption key used to encrypt the enc-part
164 Tung & Zhu Expires April 22, 2006 [Page 3]
166 Internet-Draft PKINIT October 2005
169 field of the KDC-REP in the AS-REP [RFC4120] is referred to as the AS
175 This section describes extensions to [RFC4120] for supporting the use
176 of public-key cryptography in the initial request for a ticket.
178 Briefly, this document defines the following extensions to [RFC4120]:
180 1. The client indicates the use of public-key authentication by
181 including a special preauthenticator in the initial request. This
182 preauthenticator contains the client's public-key data and a
185 2. The KDC tests the client's request against its authentication
186 policy and trusted Certification Authorities (CAs).
188 3. If the request passes the verification tests, the KDC replies as
189 usual, but the reply is encrypted using either:
191 a. a key generated through a Diffie-Hellman (DH) key exchange
192 [RFC2631] [IEEE1363] with the client, signed using the KDC's
195 b. a symmetric encryption key, signed using the KDC's signature
196 key and encrypted using the client's public key.
198 Any keying material required by the client to obtain the
199 encryption key for decrypting the KDC reply is returned in a pre-
200 authentication field accompanying the usual reply.
202 4. The client validates the KDC's signature, obtains the encryption
203 key, decrypts the reply, and then proceeds as usual.
205 Section 3.1 of this document enumerates the required algorithms and
206 necessary extension message types. Section 3.2 describes the
207 extension messages in greater detail.
209 3.1. Definitions, Requirements, and Constants
211 3.1.1. Required Algorithms
213 All PKINIT implementations MUST support the following algorithms:
220 Tung & Zhu Expires April 22, 2006 [Page 4]
222 Internet-Draft PKINIT October 2005
225 o AS reply key enctype: aes128-cts-hmac-sha1-96 and aes256-cts-hmac-
228 o Signature algorithm: sha-1WithRSAEncryption [RFC3279].
230 o AS reply key delivery method: Diffie-Hellman key exchange
233 In addition, implementations of this specification MUST be capable of
234 processing the Extended Key Usage (EKU) extension and the id-pkinit-
235 san (as defined in Section 3.2.2) otherName of the Subject
236 Alternative Name (SAN) extension in X.509 certificates [RFC3280], if
239 3.1.2. Defined Message and Encryption Types
241 PKINIT makes use of the following new pre-authentication types:
246 PKINIT also makes use of the following new authorization data type:
248 AD_INITIAL_VERIFIED_CAS 9
250 PKINIT introduces the following new error codes:
252 KDC_ERR_CLIENT_NOT_TRUSTED 62
253 KDC_ERR_INVALID_SIG 64
254 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 65
255 KDC_ERR_CANT_VERIFY_CERTIFICATE 70
256 KDC_ERR_INVALID_CERTIFICATE 71
257 KDC_ERR_REVOKED_CERTIFICATE 72
258 KDC_ERR_REVOCATION_STATUS_UNKNOWN 73
259 KDC_ERR_CLIENT_NAME_MISMATCH 75
260 KDC_ERR_INCONSISTENT_KEY_PURPOSE 76
262 PKINIT uses the following typed data types for errors:
264 TD_TRUSTED_CERTIFIERS 104
265 TD_INVALID_CERTIFICATES 105
268 PKINIT defines the following encryption types, for use in the etype
269 field of the AS-REQ [RFC4120] message to indicate acceptance of the
270 corresponding algorithms that can used by Cryptographic Message
271 Syntax (CMS) [RFC3852] messages in the reply:
276 Tung & Zhu Expires April 22, 2006 [Page 5]
278 Internet-Draft PKINIT October 2005
282 -- Indicates that the client supports dsaWithSHA1
283 md5WithRSAEncryption-CmsOID 10
284 -- Indicates that the client supports md5WithRSAEncryption
285 sha1WithRSAEncryption-CmsOID 11
286 -- Indicates that the client supports sha1WithRSAEncryption
288 -- Indicates that the client supports rc2CBC
289 rsaEncryption-EnvOID 13
290 -- Indicates that the client supports
291 -- rsaEncryption (PKCS1 v2.1)
292 id-RSAES-OAEP-EnvOID 14
293 -- Indicates that the client supports
294 -- id-RSAES-OAEP (PKCS1 v2.1)
295 des-ede3-cbc-EnvOID 15
296 -- Indicates that the client supports des-ede3-cbc
298 The ASN.1 module for all structures defined in this document (plus
299 IMPORT statements for all imported structures) is given in
302 All structures defined in or imported into this document MUST be
303 encoded using Distinguished Encoding Rules (DER) [X680] [X690]
304 (unless otherwise noted). All data structures carried in OCTET
305 STRINGs must be encoded according to the rules specified in
306 corresponding specifications.
308 Interoperability note: Some implementations may not be able to decode
309 wrapped CMS objects encoded with BER but not DER; specifically, they
310 may not be able to decode infinite length encodings. To maximize
311 interoperability, implementers SHOULD encode CMS objects used in
314 3.1.3. Algorithm Identifiers
316 PKINIT does not define, but does make use of, the following algorithm
319 PKINIT uses the following algorithm identifier(s) for Diffie-Hellman
320 key agreement [RFC3279]:
322 dhpublicnumber (Modular Exponential Diffie-Hellman [RFC2631])
324 PKINIT uses the following signature algorithm identifiers [RFC3279]:
326 sha-1WithRSAEncryption (RSA with SHA1)
327 md5WithRSAEncryption (RSA with MD5)
328 id-dsa-with-sha1 (DSA with SHA1)
332 Tung & Zhu Expires April 22, 2006 [Page 6]
334 Internet-Draft PKINIT October 2005
337 PKINIT uses the following encryption algorithm identifiers [RFC3447]
338 for encrypting the temporary key with a public key:
340 rsaEncryption (PKCS1 v2.1)
341 id-RSAES-OAEP (PKCS1 v2.1)
343 PKINIT uses the following algorithm identifiers [RFC3370] [RFC3565]
344 for encrypting the AS reply key with the temporary key:
346 des-ede3-cbc (three-key 3DES, CBC mode)
347 rc2-cbc (RC2, CBC mode)
348 id-aes256-CBC (AES-256, CBC mode)
350 3.2. PKINIT Pre-authentication Syntax and Use
352 This section defines the syntax and use of the various pre-
353 authentication fields employed by PKINIT.
355 3.2.1. Generation of Client Request
357 The initial authentication request (AS-REQ) is sent as per [RFC4120];
358 in addition, a pre-authentication data element, whose padata-type is
359 PA_PK_AS_REQ and whose padata-value contains the DER encoding of the
360 type PA-PK-AS-REQ, is included.
362 PA-PK-AS-REQ ::= SEQUENCE {
363 signedAuthPack [0] IMPLICIT OCTET STRING,
364 -- Contains a CMS type ContentInfo encoded
365 -- according to [RFC3852].
366 -- The contentType field of the type ContentInfo
367 -- is id-signedData (1.2.840.113549.1.7.2),
368 -- and the content field is a SignedData.
369 -- The eContentType field for the type SignedData is
370 -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
371 -- eContent field contains the DER encoding of the
373 -- AuthPack is defined below.
374 trustedCertifiers [1] SEQUENCE OF
375 ExternalPrincipalIdentifier OPTIONAL,
376 -- A list of CAs, trusted by the client, that can
377 -- be used to certify the KDC.
378 -- Each ExternalPrincipalIdentifier identifies a CA
379 -- or a CA certificate (thereby its public key).
380 -- The information contained in the
381 -- trustedCertifiers SHOULD be used by the KDC as
382 -- hints to guide its selection of an appropriate
383 -- certificate chain to return to the client.
384 kdcPkId [2] IMPLICIT OCTET STRING
388 Tung & Zhu Expires April 22, 2006 [Page 7]
390 Internet-Draft PKINIT October 2005
394 -- Contains a CMS type SignerIdentifier encoded
395 -- according to [RFC3852].
396 -- Identifies, if present, a particular KDC
397 -- public key that the client already has.
401 DHNonce ::= OCTET STRING
403 ExternalPrincipalIdentifier ::= SEQUENCE {
404 subjectName [0] IMPLICIT OCTET STRING OPTIONAL,
405 -- Contains a PKIX type Name encoded according to
407 -- Identifies the certificate subject by the
408 -- distinguished subject name.
409 -- REQUIRED when there is a distinguished subject
410 -- name present in the certificate.
411 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL,
412 -- Contains a CMS type IssuerAndSerialNumber encoded
413 -- according to [RFC3852].
414 -- Identifies a certificate of the subject.
415 -- REQUIRED for TD-INVALID-CERTIFICATES and
416 -- TD-TRUSTED-CERTIFIERS.
417 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL,
418 -- Identifies the subject's public key by a key
419 -- identifier. When an X.509 certificate is
420 -- referenced, this key identifier matches the X.509
421 -- subjectKeyIdentifier extension value. When other
422 -- certificate formats are referenced, the documents
423 -- that specify the certificate format and their use
424 -- with the CMS must include details on matching the
425 -- key identifier to the appropriate certificate
427 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
431 AuthPack ::= SEQUENCE {
432 pkAuthenticator [0] PKAuthenticator,
433 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
434 -- Type SubjectPublicKeyInfo is defined in
436 -- Specifies Diffie-Hellman domain parameters
437 -- and the client's public key value [IEEE1363].
438 -- The DH public key value is encoded as a BIT
439 -- STRING according to [RFC3279].
440 -- This field is present only if the client wishes
444 Tung & Zhu Expires April 22, 2006 [Page 8]
446 Internet-Draft PKINIT October 2005
449 -- to use the Diffie-Hellman key agreement method.
450 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
452 -- Type AlgorithmIdentifier is defined in
454 -- List of CMS encryption types supported by the
455 -- client in order of (decreasing) preference.
456 clientDHNonce [3] DHNonce OPTIONAL,
457 -- Present only if the client indicates that it
458 -- wishes to reuse DH keys or to allow the KDC to
459 -- do so (see Section 3.2.3.1).
463 PKAuthenticator ::= SEQUENCE {
464 cusec [0] INTEGER (0..999999),
465 ctime [1] KerberosTime,
466 -- cusec and ctime are used as in [RFC4120], for
467 -- replay prevention.
468 nonce [2] INTEGER (0..4294967295),
469 -- Chosen randomly; This nonce does not need to
470 -- match with the nonce in the KDC-REQ-BODY.
471 paChecksum [3] OCTET STRING,
472 -- Contains the SHA1 checksum, performed over
477 The ContentInfo [RFC3852] structure for the signedAuthPack field is
478 filled out as follows:
480 1. The contentType field of the type ContentInfo is id-signedData
481 (as defined in [RFC3852]), and the content field is a SignedData
482 (as defined in [RFC3852]).
484 2. The eContentType field for the type SignedData is id-pkinit-
485 authData: { iso(1) org(3) dod(6) internet(1) security(5)
486 kerberosv5(2) pkinit(3) authData(1) }.
488 3. The eContent field for the type SignedData contains the DER
489 encoding of the type AuthPack.
491 4. The signerInfos field of the type SignedData contains a single
492 signerInfo, which contains the signature over the type AuthPack.
494 5. The certificates field of the type SignedData contains
495 certificates intended to facilitate certification path
496 construction, so that the KDC can verify the signature over the
500 Tung & Zhu Expires April 22, 2006 [Page 9]
502 Internet-Draft PKINIT October 2005
505 type AuthPack. For path validation, these certificates SHOULD be
506 sufficient to construct at least one certification path from the
507 client certificate to one trust anchor acceptable by the KDC
508 [CAPATH]. The client MUST be capable of including such a set of
509 certificates if configured to do so. The certificates field MUST
510 NOT contain "root" CA certificates.
512 6. The client's Diffie-Hellman public value (clientPublicValue) is
513 included if and only if the client wishes to use the Diffie-
514 Hellman key agreement method. The Diffie-Hellman domain
515 parameters [IEEE1363] for the client's public key are specified
516 in the algorithm field of the type SubjectPublicKeyInfo [RFC3279]
517 and the client's Diffie-Hellman public key value is mapped to a
518 subjectPublicKey (a BIT STRING) according to [RFC3279]. When
519 using the Diffie-Hellman key agreement method, implementations
520 MUST support Oakley 1024-bit Modular Exponential (MODP) well-
521 known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group
522 14 [RFC3526], and SHOULD support Oakley 4096-bit MODP well-known
525 The Diffie-Hellman field size should be chosen so as to provide
526 sufficient cryptographic security [RFC3766].
528 When MODP Diffie-Hellman is used, the exponents should have at
529 least twice as many bits as the symmetric keys that will be
530 derived from them [ODL99].
532 7. The client may wish to reuse DH keys or to allow the KDC to do so
533 (see Section 3.2.3.1). If so, then the client includes the
534 clientDHNonce field. This nonce string needs to be as long as
535 the longest key length of the symmetric key types that the client
536 supports. This nonce MUST be chosen randomly.
539 3.2.2. Receipt of Client Request
541 Upon receiving the client's request, the KDC validates it. This
542 section describes the steps that the KDC MUST (unless otherwise
543 noted) take in validating the request.
545 The KDC verifies the client's signature in the signedAuthPack field
546 according to [RFC3852].
548 If, while validating the client's X.509 certificate [RFC3280], the
549 KDC cannot build a certification path to validate the client's
550 certificate, it sends back a KRB-ERROR [RFC4120] message with the
551 code KDC_ERR_CANT_VERIFY_CERTIFICATE. The accompanying e-data for
552 this error message is a TYPED-DATA (as defined in [RFC4120]) that
556 Tung & Zhu Expires April 22, 2006 [Page 10]
558 Internet-Draft PKINIT October 2005
561 contains an element whose data-type is TD_TRUSTED_CERTIFIERS, and
562 whose data-value contains the DER encoding of the type TD-TRUSTED-
565 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
566 ExternalPrincipalIdentifier
567 -- Identifies a list of CAs trusted by the KDC.
568 -- Each ExternalPrincipalIdentifier identifies a CA
569 -- or a CA certificate (thereby its public key).
571 Upon receiving this error message, the client SHOULD retry only if it
572 has a different set of certificates (from those of the previous
573 requests) that form a certification path (or a partial path) from one
574 of the trust anchors acceptable by the KDC to its own certificate.
576 If, while processing the certification path, the KDC determines that
577 the signature on one of the certificates in the signedAuthPack field
578 is invalid, it returns a KRB-ERROR [RFC4120] message with the code
579 KDC_ERR_INVALID_CERTIFICATE. The accompanying e-data for this error
580 message is a TYPED-DATA that contains an element whose data-type is
581 TD_INVALID_CERTIFICATES, and whose data-value contains the DER
582 encoding of the type TD-INVALID-CERTIFICATES:
584 TD-INVALID-CERTIFICATES ::= SEQUENCE OF
585 ExternalPrincipalIdentifier
586 -- Each ExternalPrincipalIdentifier identifies a
587 -- certificate (sent by the client) with an invalid
590 If more than one X.509 certificate signature is invalid, the KDC MAY
591 include one IssuerAndSerialNumber per invalid signature within the
592 TD-INVALID-CERTIFICATES.
594 The client's X.509 certificate is validated according to [RFC3280].
596 Based on local policy, the KDC may also check whether any X.509
597 certificates in the certification path validating the client's
598 certificate have been revoked. If any of them have been revoked, the
599 KDC MUST return an error message with the code
600 KDC_ERR_REVOKED_CERTIFICATE; if the KDC attempts to determine the
601 revocation status but is unable to do so, it SHOULD return an error
602 message with the code KDC_ERR_REVOCATION_STATUS_UNKNOWN. The
603 certificate or certificates affected are identified exactly as for
604 the error code KDC_ERR_INVALID_CERTIFICATE (see above).
606 Note that the TD_INVALID_CERTIFICATES error data is only used to
607 identify invalid certificates sent by the client in the request.
612 Tung & Zhu Expires April 22, 2006 [Page 11]
614 Internet-Draft PKINIT October 2005
617 The client's public key is then used to verify the signature. If the
618 signature fails to verify, the KDC MUST return an error message with
619 the code KDC_ERR_INVALID_SIG. There is no accompanying e-data for
622 In addition to validating the client's signature, the KDC MUST also
623 check that the client's public key used to verify the client's
624 signature is bound to the client's principal name as specified in the
627 1. If the KDC has its own binding between either the client's
628 signature-verification public key or the client's certificate and
629 the client's Kerberos principal name, it uses that binding.
631 2. Otherwise, if the client's X.509 certificate contains a Subject
632 Alternative Name (SAN) extension carrying a KRB5PrincipalName
633 (defined below) in the otherName field of the type GeneralName
634 [RFC3280], it binds the client's X.509 certificate to that name.
636 The type of the otherName field is AnotherName. The type-id field
637 of the type AnotherName is id-pkinit-san:
639 id-pkinit-san OBJECT IDENTIFIER ::=
640 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
643 And the value field of the type AnotherName is a
646 KRB5PrincipalName ::= SEQUENCE {
648 principalName [1] PrincipalName
651 If the KDC does not have its own binding and there is no
652 KRB5PrincipalName name present in the client's X.509 certificate, or
653 if the Kerberos name in the request does not match the
654 KRB5PrincipalName in the client's X.509 certificate (including the
655 realm name), the KDC MUST return an error message with the code
656 KDC_ERR_CLIENT_NAME_MISMATCH. There is no accompanying e-data for
659 Even if the certification path is validated and the certificate is
660 mapped to the client's principal name, the KDC may decide not to
661 accept the client's certificate, depending on local policy.
663 The KDC MAY require the presence of an Extended Key Usage (EKU)
664 KeyPurposeId [RFC3280] id-pkinit-KPClientAuth in the extensions field
668 Tung & Zhu Expires April 22, 2006 [Page 12]
670 Internet-Draft PKINIT October 2005
673 of the client's X.509 certificate:
675 id-pkinit-KPClientAuth OBJECT IDENTIFIER ::=
676 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
677 pkinit(3) keyPurposeClientAuth(4) }
678 -- PKINIT client authentication.
679 -- Key usage bits that MUST be consistent:
682 If this EKU KeyPurposeId is required but it is not present or if the
683 client certificate is restricted not to be used for PKINIT client
684 authentication per Section 4.2.1.13 of [RFC3280], the KDC MUST return
685 an error message of the code KDC_ERR_INCONSISTENT_KEY_PURPOSE. There
686 is no accompanying e-data for this error message. KDCs implementing
687 this requirement SHOULD also accept the EKU KeyPurposeId id-ms-kp-sc-
688 logon (1.3.6.1.4.1.311.20.2.2) as meeting the requirement, as there
689 are a large number of X.509 client certificates deployed for use with
690 PKINIT which have this EKU.
692 As a matter of local policy, the KDC MAY decide to reject requests on
693 the basis of the absence or presence of other specific EKU OID's.
695 If the client's public key is not accepted, the KDC returns an error
696 message with the code KDC_ERR_CLIENT_NOT_TRUSTED.
698 The KDC MUST check the timestamp to ensure that the request is not a
699 replay, and that the time skew falls within acceptable limits. The
700 recommendations for clock skew times in [RFC4120] apply here. If the
701 check fails, the KDC MUST return error code KRB_AP_ERR_REPEAT or
702 KRB_AP_ERR_SKEW, respectively.
704 If the clientPublicValue is filled in, indicating that the client
705 wishes to use the Diffie-Hellman key agreement method, the KDC SHOULD
706 check to see if the key parameters satisfy its policy. If they do
707 not, it MUST return an error message with the code
708 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED. The accompanying e-data is a
709 TYPED-DATA that contains an element whose data-type is
710 TD_DH_PARAMETERS, and whose data-value contains the DER encoding of
711 the type TD-DH-PARAMETERS:
713 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
714 -- Each AlgorithmIdentifier specifies a set of
715 -- Diffie-Hellman domain parameters [IEEE1363].
716 -- This list is in decreasing preference order.
718 TD-DH-PARAMETERS contains a list of Diffie-Hellman domain parameters
719 that the KDC supports in decreasing preference order, from which the
720 client SHOULD pick one to retry the request.
724 Tung & Zhu Expires April 22, 2006 [Page 13]
726 Internet-Draft PKINIT October 2005
729 If the client included a kdcPkId field in the PA-PK-AS-REQ and the
730 KDC does not possess the corresponding key, the KDC MUST ignore the
731 kdcPkId field as if the client did not include one.
733 If there is a supportedCMSTypes field in the AuthPack, the KDC must
734 check to see if it supports any of the listed types. If it supports
735 more than one of the types, the KDC SHOULD use the one listed first.
736 If it does not support any of them, it MUST return an error message
737 with the code KDC_ERR_ETYPE_NOSUPP [RFC4120].
739 3.2.3. Generation of KDC Reply
741 Assuming that the client's request has been properly validated, the
742 KDC proceeds as per [RFC4120], except as follows.
744 The KDC MUST set the initial flag and include an authorization data
745 element of ad-type [RFC4120] AD_INITIAL_VERIFIED_CAS in the issued
746 ticket. The ad-data [RFC4120] field contains the DER encoding of the
747 type AD-INITIAL-VERIFIED-CAS:
749 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
750 ExternalPrincipalIdentifier
751 -- Identifies the certification path based on which
752 -- the client certificate was validated.
753 -- Each ExternalPrincipalIdentifier identifies a CA
754 -- or a CA certificate (thereby its public key).
756 The AS wraps any AD-INITIAL-VERIFIED-CAS data in AD-IF-RELEVANT
757 containers if the list of CAs satisfies the AS' realm's local policy
758 (this corresponds to the TRANSITED-POLICY-CHECKED ticket flag
759 [RFC4120]). Furthermore, any TGS MUST copy such authorization data
760 from tickets used within a PA-TGS-REQ of the TGS-REQ into the
761 resulting ticket. If the list of CAs satisfies the local KDC's
762 realm's policy, the TGS MAY wrap the data into the AD-IF-RELEVANT
763 container, otherwise it MAY unwrap the authorization data out of the
764 AD-IF-RELEVANT container.
766 Application servers that understand this authorization data type
767 SHOULD apply local policy to determine whether a given ticket bearing
768 such a type *not* contained within an AD-IF-RELEVANT container is
769 acceptable. (This corresponds to the AP server checking the
770 transited field when the TRANSITED-POLICY-CHECKED flag has not been
771 set [RFC4120].) If such a data type is contained within an AD-IF-
772 RELEVANT container, AP servers MAY apply local policy to determine
773 whether the authorization data is acceptable.
775 A pre-authentication data element, whose padata-type is PA_PK_AS_REP
776 and whose padata-value contains the DER encoding of the type PA-PK-
780 Tung & Zhu Expires April 22, 2006 [Page 14]
782 Internet-Draft PKINIT October 2005
785 AS-REP (defined below), is included in the AS-REP [RFC4120].
787 PA-PK-AS-REP ::= CHOICE {
788 dhInfo [0] DHRepInfo,
789 -- Selected when Diffie-Hellman key exchange is
791 encKeyPack [1] IMPLICIT OCTET STRING,
792 -- Selected when public key encryption is used.
793 -- Contains a CMS type ContentInfo encoded
794 -- according to [RFC3852].
795 -- The contentType field of the type ContentInfo is
796 -- id-envelopedData (1.2.840.113549.1.7.3).
797 -- The content field is an EnvelopedData.
798 -- The contentType field for the type EnvelopedData
799 -- is id-signedData (1.2.840.113549.1.7.2).
800 -- The eContentType field for the inner type
801 -- SignedData (when unencrypted) is
802 -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
803 -- eContent field contains the DER encoding of the
804 -- type ReplyKeyPack.
805 -- ReplyKeyPack is defined in Section 3.2.3.2.
809 DHRepInfo ::= SEQUENCE {
810 dhSignedData [0] IMPLICIT OCTET STRING,
811 -- Contains a CMS type ContentInfo encoded according
813 -- The contentType field of the type ContentInfo is
814 -- id-signedData (1.2.840.113549.1.7.2), and the
815 -- content field is a SignedData.
816 -- The eContentType field for the type SignedData is
817 -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
818 -- eContent field contains the DER encoding of the
819 -- type KDCDHKeyInfo.
820 -- KDCDHKeyInfo is defined below.
821 serverDHNonce [1] DHNonce OPTIONAL
822 -- Present if and only if dhKeyExpiration is
823 -- present in the KDCDHKeyInfo.
826 KDCDHKeyInfo ::= SEQUENCE {
827 subjectPublicKey [0] BIT STRING,
828 -- KDC's DH public key.
829 -- The DH public key value is encoded as a BIT
830 -- STRING according to [RFC3279].
831 nonce [1] INTEGER (0..4294967295),
832 -- Contains the nonce in the PKAuthenticator of the
836 Tung & Zhu Expires April 22, 2006 [Page 15]
838 Internet-Draft PKINIT October 2005
841 -- request if DH keys are NOT reused,
843 dhKeyExpiration [2] KerberosTime OPTIONAL,
844 -- Expiration time for KDC's key pair,
845 -- present if and only if DH keys are reused. If
846 -- this field is omitted then the serverDHNonce
847 -- field MUST also be omitted. See Section 3.2.3.1.
851 The content of the AS-REP is otherwise unchanged from [RFC4120]. The
852 KDC encrypts the reply as usual, but not with the client's long-term
853 key. Instead, it encrypts it with either a shared key derived from a
854 Diffie-Hellman exchange, or a generated encryption key. The contents
855 of the PA-PK-AS-REP indicate which key delivery method is used.
857 In addition, the lifetime of the ticket returned by the KDC MUST NOT
858 exceed that of the client's public-private key pair. The ticket
859 lifetime, however, can be shorter than that of the client's public-
860 private key pair. For the implementations of this specification, the
861 lifetime of the client's public-private key pair is the validity
862 period in X.509 certificates [RFC3280], unless configured otherwise.
864 3.2.3.1. Using Diffie-Hellman Key Exchange
866 In this case, the PA-PK-AS-REP contains a DHRepInfo structure.
868 The ContentInfo [RFC3852] structure for the dhSignedData field is
869 filled in as follows:
871 1. The contentType field of the type ContentInfo is id-signedData
872 (as defined in [RFC3852]), and the content field is a SignedData
873 (as defined in [RFC3852]).
875 2. The eContentType field for the type SignedData is the OID value
876 for id-pkinit-DHKeyData: { iso(1) org(3) dod(6) internet(1)
877 security(5) kerberosv5(2) pkinit(3) DHKeyData(2) }.
879 3. The eContent field for the type SignedData contains the DER
880 encoding of the type KDCDHKeyInfo.
882 4. The signerInfos field of the type SignedData contains a single
883 signerInfo, which contains the signature over the type
886 5. The certificates field of the type SignedData contains
887 certificates intended to facilitate certification path
888 construction, so that the client can verify the KDC's signature
892 Tung & Zhu Expires April 22, 2006 [Page 16]
894 Internet-Draft PKINIT October 2005
897 over the type KDCDHKeyInfo. The information contained in the
898 trustedCertifiers in the request SHOULD be used by the KDC as
899 hints to guide its selection of an appropriate certificate chain
900 to return to the client. This field may only. be left empty if
901 the KDC public key specified by the kdcPkId field in the PA-PK-
902 AS-REQ was used for signing. Otherwise, for path validation,
903 these certificates SHOULD be sufficient to construct at least one
904 certification path from the KDC certificate to one trust anchor
905 acceptable by the client [CAPATH]. The KDC MUST be capable of
906 including such a set of certificates if configured to do so. The
907 certificates field MUST NOT contain "root" CA certificates.
909 6. If the client included the clientDHNonce field, then the KDC may
910 choose to reuse its DH keys (see Section 3.2.3.1). If the server
911 reuses DH keys then it MUST include an expiration time in the
912 dhKeyExpiration field. Past the point of the expiration time,
913 the signature over the type DHRepInfo is considered expired/
914 invalid. When the server reuses DH keys then it MUST include a
915 serverDHNonce at least as long as the length of keys for the
916 symmetric encryption system used to encrypt the AS reply. Note
917 that including the serverDHNonce changes how the client and
918 server calculate the key to use to encrypt the reply; see below
919 for details. The KDC SHOULD NOT reuse DH keys unless the
920 clientDHNonce field is present in the request.
922 The AS reply key is derived as follows:
924 1. Both the KDC and the client calculate the shared secret value as
927 a) When MODP Diffie-Hellman is used, let DHSharedSecret be the
928 shared secret value. DHSharedSecret is the value ZZ as
929 described in Section 2.1.1 of [RFC2631].
931 DHSharedSecret is first padded with leading zeros such that the
932 size of DHSharedSecret in octets is the same as that of the
933 modulus, then represented as a string of octets in big-endian
936 Implementation note: Both the client and the KDC can cache the
937 triple (ya, yb, DHSharedSecret), where ya is the client's public
938 key and yb is the KDC's public key. If both ya and yb are the
939 same in a later exchange, the cached DHSharedSecret can be used.
948 Tung & Zhu Expires April 22, 2006 [Page 17]
950 Internet-Draft PKINIT October 2005
953 2. Let K be the key-generation seed length [RFC3961] of the AS reply
954 key whose enctype is selected according to [RFC4120].
956 3. Define the function octetstring2key() as follows:
958 octetstring2key(x) == random-to-key(K-truncate(
965 where x is an octet string; | is the concatenation operator; 0x00,
966 0x01, 0x02, etc., are each represented as a single octet; random-
967 to-key() is an operation that generates a protocol key from a
968 bitstring of length K; and K-truncate truncates its input to the
969 first K bits. Both K and random-to-key() are as defined in the
970 kcrypto profile [RFC3961] for the enctype of the AS reply key.
972 4. When DH keys are reused, let n_c be the clientDHNonce, and n_k be
973 the serverDHNonce; otherwise, let both n_c and n_k be empty octet
976 5. The AS reply key k is:
978 k = octetstring2key(DHSharedSecret | n_c | n_k)
980 3.2.3.2. Using Public Key Encryption
982 In this case, the PA-PK-AS-REP contains a ContentInfo structure
983 wrapped in an OCTET STRING. The AS reply key is encrypted in the
984 encKeyPack field, which contains data of type ReplyKeyPack:
1004 Tung & Zhu Expires April 22, 2006 [Page 18]
1006 Internet-Draft PKINIT October 2005
1009 ReplyKeyPack ::= SEQUENCE {
1010 replyKey [0] EncryptionKey,
1011 -- Contains the session key used to encrypt the
1012 -- enc-part field in the AS-REP.
1013 asChecksum [1] Checksum,
1014 -- Contains the checksum of the AS-REQ
1015 -- corresponding to the containing AS-REP.
1016 -- The checksum is performed over the type AS-REQ.
1017 -- The protocol key [RFC3961] of the checksum is the
1018 -- replyKey and the key usage number is 6.
1019 -- If the replyKey's enctype is "newer" [RFC4120]
1020 -- [RFC4121], the checksum is the required
1021 -- checksum operation [RFC3961] for that enctype.
1022 -- The client MUST verify this checksum upon receipt
1027 The ContentInfo [RFC3852] structure for the encKeyPack field is
1028 filled in as follows:
1030 1. The contentType field of the type ContentInfo is id-envelopedData
1031 (as defined in [RFC3852]), and the content field is an
1032 EnvelopedData (as defined in [RFC3852]).
1034 2. The contentType field for the type EnvelopedData is id-
1035 signedData: { iso (1) member-body (2) us (840) rsadsi (113549)
1036 pkcs (1) pkcs7 (7) signedData (2) }.
1038 3. The eContentType field for the inner type SignedData (when
1039 decrypted from the encryptedContent field for the type
1040 EnvelopedData) is id-pkinit-rkeyData: { iso(1) org(3) dod(6)
1041 internet(1) security(5) kerberosv5(2) pkinit(3) rkeyData(3) }.
1043 4. The eContent field for the inner type SignedData contains the DER
1044 encoding of the type ReplyKeyPack.
1046 5. The signerInfos field of the inner type SignedData contains a
1047 single signerInfo, which contains the signature over the type
1050 6. The certificates field of the inner type SignedData contains
1051 certificates intended to facilitate certification path
1052 construction, so that the client can verify the KDC's signature
1053 over the type ReplyKeyPack. The information contained in the
1054 trustedCertifiers in the request SHOULD be used by the KDC as
1055 hints to guide its selection of an appropriate certificate chain
1056 to return to the client. This field may only be left empty if
1060 Tung & Zhu Expires April 22, 2006 [Page 19]
1062 Internet-Draft PKINIT October 2005
1065 the KDC public key specified by the kdcPkId field in the PA-PK-
1066 AS-REQ was used for signing. Otherwise, for path validation,
1067 these certificates SHOULD be sufficient to construct at least one
1068 certification path from the KDC certificate to one trust anchor
1069 acceptable by the client [CAPATH]. The KDC MUST be capable of
1070 including such a set of certificates if configured to do so. The
1071 certificates field MUST NOT contain "root" CA certificates.
1073 7. The recipientInfos field of the type EnvelopedData is a SET which
1074 MUST contain exactly one member of type KeyTransRecipientInfo.
1075 The encryptedKey of this member contains the temporary key which
1076 is encrypted using the client's public key.
1078 8. The unprotectedAttrs or originatorInfo fields of the type
1079 EnvelopedData MAY be present.
1081 Implementations of this RSA encryption key delivery method are
1082 RECOMMENDED to support for RSA keys at least 2048 bits in size.
1084 3.2.4. Receipt of KDC Reply
1086 Upon receipt of the KDC's reply, the client proceeds as follows. If
1087 the PA-PK-AS-REP contains the dhSignedData field, the client derives
1088 the AS reply key using the same procedure used by the KDC as defined
1089 in Section 3.2.3.1. Otherwise, the message contains the encKeyPack
1090 field, and the client decrypts and extracts the temporary key in the
1091 encryptedKey field of the member KeyTransRecipientInfo, and then uses
1092 that as the AS reply key.
1094 If the public key encryption method is used, the client MUST verify
1095 the asChecksum contained in the ReplyKeyPack.
1097 In either case, the client MUST verify the signature in the
1098 SignedData according to [RFC3852]. The KDC's X.509 certificate MUST
1099 be validated according to [RFC3280]. In addition, unless the client
1100 can otherwise verify that the public key used to verify the KDC's
1101 signature is bound to the KDC of the target realm, the KDC's X.509
1102 certificate MUST contain a Subject Alternative Name extension
1103 [RFC3280] carrying an AnotherName whose type-id is id-pkinit-san (as
1104 defined in Section 3.2.2) and whose value is a KRB5PrincipalName that
1105 matches the name of the TGS of the target realm (as defined in
1106 Section 7.3 of [RFC4120]).
1108 Unless the client knows by some other means that the KDC certificate
1109 is intended for a Kerberos KDC, the client MUST require that the KDC
1110 certificate contains the EKU KeyPurposeId [RFC3280] id-pkinit-KPKdc:
1116 Tung & Zhu Expires April 22, 2006 [Page 20]
1118 Internet-Draft PKINIT October 2005
1121 id-pkinit-KPKdc OBJECT IDENTIFIER ::=
1122 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
1123 pkinit(3) keyPurposeKdc(5) }
1124 -- Signing KDC responses.
1125 -- Key usage bits that MUST be consistent:
1126 -- digitalSignature.
1128 If the KDC certificate contains the Kerberos TGS name encoded as an
1129 id-pkinit-san SAN, this certificate is certified by the issuing CA as
1130 a KDC certificate, therefore the id-pkinit-KPKdc EKU is not required.
1132 If all applicable checks are satisfied, the client then decrypts the
1133 enc-part field of the KDC-REP in the AS-REP using the AS reply key,
1134 and then proceeds as described in [RFC4120].
1136 Implementation note: CAs issuing KDC certificates SHOULD place all
1137 "short" and "fully-qualified" Kerberos realm names of the KDC (one
1138 per GeneralName [RFC3280]) into the KDC certificate to allow maximum
1141 3.3. Interoperability Requirements
1143 The client MUST be capable of sending a set of certificates
1144 sufficient to allow the KDC to construct a certification path for the
1145 client's certificate, if the correct set of certificates is provided
1146 through configuration or policy.
1148 If the client sends all the X.509 certificates on a certification
1149 path to a trust anchor acceptable by the KDC, and the KDC can not
1150 verify the client's public key otherwise, the KDC MUST be able to
1151 process path validation for the client's certificate based on the
1152 certificates in the request.
1154 The KDC MUST be capable of sending a set of certificates sufficient
1155 to allow the client to construct a certification path for the KDC's
1156 certificate, if the correct set of certificates is provided through
1157 configuration or policy.
1159 If the KDC sends all the X.509 certificates on a certification path
1160 to a trust anchor acceptable by the client, and the client can not
1161 verify the KDC's public key otherwise, the client MUST be able to
1162 process path validation for the KDC's certificate based on the
1163 certificates in the reply.
1165 3.4. KDC Indication of PKINIT Support
1167 If pre-authentication is required, but was not present in the
1168 request, per [RFC4120] an error message with the code
1172 Tung & Zhu Expires April 22, 2006 [Page 21]
1174 Internet-Draft PKINIT October 2005
1177 KDC_ERR_PREAUTH_FAILED is returned and a METHOD-DATA object will be
1178 stored in the e-data field of the KRB-ERROR message to specify which
1179 pre-authentication mechanisms are acceptable. The KDC can then
1180 indicate the support of PKINIT by including an empty element whose
1181 padata-type is PA_PK_AS_REQ in that METHOD-DATA object.
1183 Otherwise if it is required by the KDC's local policy that the client
1184 must be pre-authenticated using the pre-authentication mechanism
1185 specified in this document, but no PKINIT pre-authentication was
1186 present in the request, an error message with the code
1187 KDC_ERR_PREAUTH_FAILED SHOULD be returned.
1189 KDCs MUST leave the padata-value field of the PA_PK_AS_REQ element in
1190 the KRB-ERROR's METHOD-DATA empty (i.e., send a zero-length OCTET
1191 STRING), and clients MUST ignore this and any other value. Future
1192 extensions to this protocol may specify other data to send instead of
1193 an empty OCTET STRING.
1196 4. Security Considerations
1198 Kerberos error messages are not integrity protected, as a result, the
1199 domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
1200 with by an attacker so that the set of domain parameters selected
1201 could be either weaker or not mutually preferred. Local policy can
1202 configure sets of domain parameters acceptable locally, or disallow
1203 the negotiation of DH domain parameters.
1205 The symmetric reply key size and Diffie-Hellman field size or RSA
1206 modulus size should be chosen so as to provide sufficient
1207 cryptographic security [RFC3766].
1209 When MODP Diffie-Hellman is used, the exponents should have at least
1210 twice as many bits as the symmetric keys that will be derived from
1213 PKINIT raises certain security considerations beyond those that can
1214 be regulated strictly in protocol definitions. We will address them
1217 PKINIT extends the cross-realm model to the public-key
1218 infrastructure. Users of PKINIT must understand security policies
1219 and procedures appropriate to the use of Public Key Infrastructures
1222 In order to trust a KDC certificate that is certified by a CA as a
1223 KDC certificate for a target realm (for example, by asserting the TGS
1224 name of that Kerberos realm as an id-pkinit-san SAN and/or
1228 Tung & Zhu Expires April 22, 2006 [Page 22]
1230 Internet-Draft PKINIT October 2005
1233 restricting the certificate usage by using the id-pkinit-KPKdc EKU,
1234 as described in Section 3.2.4), the client MUST verify that the KDC
1235 certificate's issuing CA is authorized to issue KDC certificates for
1236 that target realm. Otherwise, the binding between the KDC
1237 certificate and the KDC of the target realm is not established.
1239 How to validate this authorization is a matter of local policy. A
1240 way to achieve this is the configuration of specific sets of
1241 intermediary CAs and trust anchors, one of which must be on the KDC
1242 certificate's certification path [RFC3280]; and for each CA or trust
1243 anchor the realms for which it is allowed to issue certificates.
1245 In addition, if any CA is trusted to issue KDC certificates can also
1246 issue other kinds of certificates, then local policy must be able to
1247 distinguish between them: for example, it could require that KDC
1248 certificates contain the id-pkinit-KPKdc EKU or that the realm be
1249 specified with the id-pkinit-san SAN.
1251 It is the responsibility of the PKI administrators for an
1252 organization to ensure that KDC certificates are only issued to KDCs,
1253 and that clients can ascertain this using their local policy.
1255 Standard Kerberos allows the possibility of interactions between
1256 cryptosystems of varying strengths; this document adds interactions
1257 with public-key cryptosystems to Kerberos. Some administrative
1258 policies may allow the use of relatively weak public keys. Using
1259 such keys to wrap data encrypted under stronger conventional
1260 cryptosystems may be inappropriate.
1262 PKINIT requires keys for symmetric cryptosystems to be generated.
1263 Some such systems contain "weak" keys. For recommendations regarding
1264 these weak keys, see [RFC4120].
1266 PKINIT allows the use of the same RSA key pair for encryption and
1267 signing when doing RSA encryption based key delivery. This is not
1268 recommended usage of RSA keys [RFC3447], by using DH based key
1269 delivery this is avoided.
1271 Care should be taken in how certificates are chosen for the purposes
1272 of authentication using PKINIT. Some local policies may require that
1273 key escrow be used for certain certificate types. Deployers of
1274 PKINIT should be aware of the implications of using certificates that
1275 have escrowed keys for the purposes of authentication. Because
1276 signing only certificates are normally not escrowed, by using DH
1277 based key delivery this is avoided.
1279 PKINIT does not provide for a "return routability" test to prevent
1280 attackers from mounting a denial-of-service attack on the KDC by
1284 Tung & Zhu Expires April 22, 2006 [Page 23]
1286 Internet-Draft PKINIT October 2005
1289 causing it to perform unnecessary and expensive public-key
1290 operations. Strictly speaking, this is also true of standard
1291 Kerberos, although the potential cost is not as great, because
1292 standard Kerberos does not make use of public-key cryptography. By
1293 using DH based key delivery and reusing DH keys, the necessary crypto
1294 processing cost per request can be minimized.
1296 The syntax for the AD-INITIAL-VERIFIED-CAS authorization data does
1297 permit empty SEQUENCEs to be encoded. Such empty sequences may only
1298 be used if the KDC itself vouches for the user's certificate.
1303 The following people have made significant contributions to this
1304 draft: Paul Leach, Stefan Santesson, Sam Hartman, Love Hornquist
1305 Astrand, Ken Raeburn, Nicolas Williams, John Wray, Jonathan Trostle,
1306 Tom Yu, Jeffrey Hutzelman, David Cross, Dan Simon, Karthik
1307 Jaganathan, and Chaskiel M Grundman.
1309 Andre Scedrov, Aaron D. Jaggard, Iliano Cervesato, Joe-Kai Tsay and
1310 Chris Walstad discovered a binding issue between the AS-REQ and AS-
1311 REP in draft -26, the asChecksum field was added as the result.
1313 Special thanks to Clifford Neuman, Matthew Hur, Sasha Medvinsky and
1314 Jonathan Trostle who wrote earlier versions of this document.
1316 The authors are indebted to the Kerberos working group chair Jeffrey
1317 Hutzelman who kept track of various issues and was enormously helpful
1318 during the creation of this document.
1320 Some of the ideas on which this document is based arose during
1321 discussions over several years between members of the SAAG, the IETF
1322 CAT working group, and the PSRG, regarding integration of Kerberos
1323 and SPX. Some ideas have also been drawn from the DASS system.
1324 These changes are by no means endorsed by these groups. This is an
1325 attempt to revive some of the goals of those groups, and this
1326 document approaches those goals primarily from the Kerberos
1329 Lastly, comments from groups working on similar ideas in DCE have
1333 6. IANA Considerations
1335 This document has no actions for IANA.
1340 Tung & Zhu Expires April 22, 2006 [Page 24]
1342 Internet-Draft PKINIT October 2005
1347 7.1. Normative References
1350 IEEE, "Standard Specifications for Public Key
1351 Cryptography", IEEE 1363, 2000.
1353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1354 Requirement Levels", BCP 14, RFC 2119, March 1997.
1356 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
1357 RFC 2412, November 1998.
1359 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
1360 RFC 2631, June 1999.
1362 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
1363 Identifiers for the Internet X.509 Public Key
1364 Infrastructure Certificate and Certificate Revocation List
1365 (CRL) Profile", RFC 3279, April 2002.
1367 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
1368 X.509 Public Key Infrastructure Certificate and
1369 Certificate Revocation List (CRL) Profile", RFC 3280,
1372 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
1373 Algorithms", RFC 3370, August 2002.
1375 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
1376 Standards (PKCS) #1: RSA Cryptography Specifications
1377 Version 2.1", RFC 3447, February 2003.
1379 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
1380 Diffie-Hellman groups for Internet Key Exchange (IKE)",
1383 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES)
1384 Encryption Algorithm in Cryptographic Message Syntax
1385 (CMS)", RFC 3565, July 2003.
1387 [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
1388 Public Keys Used For Exchanging Symmetric Keys", BCP 86,
1389 RFC 3766, April 2004.
1391 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
1392 RFC 3852, July 2004.
1396 Tung & Zhu Expires April 22, 2006 [Page 25]
1398 Internet-Draft PKINIT October 2005
1401 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
1402 Kerberos 5", RFC 3961, February 2005.
1404 [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
1405 Encryption for Kerberos 5", RFC 3962, February 2005.
1407 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
1408 Kerberos Network Authentication Service (V5)", RFC 4120,
1411 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
1412 Version 5 Generic Security Service Application Program
1413 Interface (GSS-API) Mechanism: Version 2", RFC 4121,
1416 [X.509-97] ITU-T Recommendation X.509: The Directory - Authentication
1419 [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
1420 Information technology - Abstract Syntax Notation One
1421 (ASN.1): Specification of basic notation.
1423 [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
1424 Information technology - ASN.1 encoding Rules: Specification
1425 of Basic Encoding Rules (BER), Canonical Encoding Rules
1426 (CER) and Distinguished Encoding Rules (DER).
1428 7.2. Informative References
1430 [CAPATH] RFC-Editor: To be replaced by RFC number for draft-ietf-
1431 pkix-certpathbuild. Work in Progress.
1433 [LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
1434 Sizes", Journal of Cryptology 14 (2001) 255-293.
1436 [ODL99] Odlyzko, A., "Discrete logarithms: The past and the
1437 future, Designs, Codes, and Cryptography (1999)".
1440 Appendix A. PKINIT ASN.1 Module
1442 KerberosV5-PK-INIT-SPEC {
1443 iso(1) identified-organization(3) dod(6) internet(1)
1444 security(5) kerberosV5(2) modules(4) pkinit(5)
1445 } DEFINITIONS EXPLICIT TAGS ::= BEGIN
1451 Tung & Zhu Expires April 22, 2006 [Page 26]
1453 Internet-Draft PKINIT October 2005
1456 SubjectPublicKeyInfo, AlgorithmIdentifier
1457 FROM PKIX1Explicit88 { iso (1)
1458 identified-organization (3) dod (6) internet (1)
1459 security (5) mechanisms (5) pkix (7) id-mod (0)
1460 id-pkix1-explicit (18) }
1461 -- As defined in RFC 3280.
1463 KerberosTime, PrincipalName, Realm, EncryptionKey
1464 FROM KerberosV5Spec2 { iso(1) identified-organization(3)
1465 dod(6) internet(1) security(5) kerberosV5(2)
1466 modules(4) krb5spec2(2) } ;
1468 id-pkinit OBJECT IDENTIFIER ::=
1469 { iso (1) org (3) dod (6) internet (1) security (5)
1470 kerberosv5 (2) pkinit (3) }
1472 id-pkinit-authData OBJECT IDENTIFIER ::= { id-pkinit 1 }
1473 id-pkinit-DHKeyData OBJECT IDENTIFIER ::= { id-pkinit 2 }
1474 id-pkinit-rkeyData OBJECT IDENTIFIER ::= { id-pkinit 3 }
1475 id-pkinit-KPClientAuth OBJECT IDENTIFIER ::= { id-pkinit 4 }
1476 id-pkinit-KPKdc OBJECT IDENTIFIER ::= { id-pkinit 5 }
1478 id-pkinit-san OBJECT IDENTIFIER ::=
1479 { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2)
1482 pa-pk-as-req INTEGER ::= 16
1483 pa-pk-as-rep INTEGER ::= 17
1485 ad-initial-verified-cas INTEGER ::= 9
1487 td-trusted-certifiers INTEGER ::= 104
1488 td-invalid-certificates INTEGER ::= 105
1489 td-dh-parameters INTEGER ::= 109
1491 PA-PK-AS-REQ ::= SEQUENCE {
1492 signedAuthPack [0] IMPLICIT OCTET STRING,
1493 -- Contains a CMS type ContentInfo encoded
1494 -- according to [RFC3852].
1495 -- The contentType field of the type ContentInfo
1496 -- is id-signedData (1.2.840.113549.1.7.2),
1497 -- and the content field is a SignedData.
1498 -- The eContentType field for the type SignedData is
1499 -- id-pkinit-authData (1.3.6.1.5.2.3.1), and the
1500 -- eContent field contains the DER encoding of the
1502 -- AuthPack is defined below.
1503 trustedCertifiers [1] SEQUENCE OF
1507 Tung & Zhu Expires April 22, 2006 [Page 27]
1509 Internet-Draft PKINIT October 2005
1512 ExternalPrincipalIdentifier OPTIONAL,
1513 -- A list of CAs, trusted by the client, that can
1514 -- be used to certify the KDC.
1515 -- Each ExternalPrincipalIdentifier identifies a CA
1516 -- or a CA certificate (thereby its public key).
1517 -- The information contained in the
1518 -- trustedCertifiers SHOULD be used by the KDC as
1519 -- hints to guide its selection of an appropriate
1520 -- certificate chain to return to the client.
1521 kdcPkId [2] IMPLICIT OCTET STRING
1523 -- Contains a CMS type SignerIdentifier encoded
1524 -- according to [RFC3852].
1525 -- Identifies, if present, a particular KDC
1526 -- public key that the client already has.
1530 DHNonce ::= OCTET STRING
1532 ExternalPrincipalIdentifier ::= SEQUENCE {
1533 subjectName [0] IMPLICIT OCTET STRING OPTIONAL,
1534 -- Contains a PKIX type Name encoded according to
1536 -- Identifies the certificate subject by the
1537 -- distinguished subject name.
1538 -- REQUIRED when there is a distinguished subject
1539 -- name present in the certificate.
1540 issuerAndSerialNumber [1] IMPLICIT OCTET STRING OPTIONAL,
1541 -- Contains a CMS type IssuerAndSerialNumber encoded
1542 -- according to [RFC3852].
1543 -- Identifies a certificate of the subject.
1544 -- REQUIRED for TD-INVALID-CERTIFICATES and
1545 -- TD-TRUSTED-CERTIFIERS.
1546 subjectKeyIdentifier [2] IMPLICIT OCTET STRING OPTIONAL,
1547 -- Identifies the subject's public key by a key
1548 -- identifier. When an X.509 certificate is
1549 -- referenced, this key identifier matches the X.509
1550 -- subjectKeyIdentifier extension value. When other
1551 -- certificate formats are referenced, the documents
1552 -- that specify the certificate format and their use
1553 -- with the CMS must include details on matching the
1554 -- key identifier to the appropriate certificate
1556 -- RECOMMENDED for TD-TRUSTED-CERTIFIERS.
1563 Tung & Zhu Expires April 22, 2006 [Page 28]
1565 Internet-Draft PKINIT October 2005
1568 AuthPack ::= SEQUENCE {
1569 pkAuthenticator [0] PKAuthenticator,
1570 clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL,
1571 -- Type SubjectPublicKeyInfo is defined in
1573 -- Specifies Diffie-Hellman domain parameters
1574 -- and the client's public key value [IEEE1363].
1575 -- The DH public key value is encoded as a BIT
1576 -- STRING according to [RFC3279].
1577 -- This field is present only if the client wishes
1578 -- to use the Diffie-Hellman key agreement method.
1579 supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier
1581 -- Type AlgorithmIdentifier is defined in
1583 -- List of CMS encryption types supported by the
1584 -- client in order of (decreasing) preference.
1585 clientDHNonce [3] DHNonce OPTIONAL,
1586 -- Present only if the client indicates that it
1587 -- wishes to reuse DH keys or to allow the KDC to
1592 PKAuthenticator ::= SEQUENCE {
1593 cusec [0] INTEGER (0..999999),
1594 ctime [1] KerberosTime,
1595 -- cusec and ctime are used as in [RFC4120], for
1596 -- replay prevention.
1597 nonce [2] INTEGER (0..4294967295),
1598 -- Chosen randomly; This nonce does not need to
1599 -- match with the nonce in the KDC-REQ-BODY.
1600 paChecksum [3] OCTET STRING,
1601 -- Contains the SHA1 checksum, performed over
1606 TD-TRUSTED-CERTIFIERS ::= SEQUENCE OF
1607 ExternalPrincipalIdentifier
1608 -- Identifies a list of CAs trusted by the KDC.
1609 -- Each ExternalPrincipalIdentifier identifies a CA
1610 -- or a CA certificate (thereby its public key).
1612 TD-INVALID-CERTIFICATES ::= SEQUENCE OF
1613 ExternalPrincipalIdentifier
1614 -- Each ExternalPrincipalIdentifier identifies a
1615 -- certificate (sent by the client) with an invalid
1619 Tung & Zhu Expires April 22, 2006 [Page 29]
1621 Internet-Draft PKINIT October 2005
1626 KRB5PrincipalName ::= SEQUENCE {
1628 principalName [1] PrincipalName
1631 AD-INITIAL-VERIFIED-CAS ::= SEQUENCE OF
1632 ExternalPrincipalIdentifier
1633 -- Identifies the certification path based on which
1634 -- the client certificate was validated.
1635 -- Each ExternalPrincipalIdentifier identifies a CA
1636 -- or a CA certificate (thereby its public key).
1638 PA-PK-AS-REP ::= CHOICE {
1639 dhInfo [0] DHRepInfo,
1640 -- Selected when Diffie-Hellman key exchange is
1642 encKeyPack [1] IMPLICIT OCTET STRING,
1643 -- Selected when public key encryption is used.
1644 -- Contains a CMS type ContentInfo encoded
1645 -- according to [RFC3852].
1646 -- The contentType field of the type ContentInfo is
1647 -- id-envelopedData (1.2.840.113549.1.7.3).
1648 -- The content field is an EnvelopedData.
1649 -- The contentType field for the type EnvelopedData
1650 -- is id-signedData (1.2.840.113549.1.7.2).
1651 -- The eContentType field for the inner type
1652 -- SignedData (when unencrypted) is
1653 -- id-pkinit-rkeyData (1.3.6.1.5.2.3.3) and the
1654 -- eContent field contains the DER encoding of the
1655 -- type ReplyKeyPack.
1656 -- ReplyKeyPack is defined below.
1660 DHRepInfo ::= SEQUENCE {
1661 dhSignedData [0] IMPLICIT OCTET STRING,
1662 -- Contains a CMS type ContentInfo encoded according
1664 -- The contentType field of the type ContentInfo is
1665 -- id-signedData (1.2.840.113549.1.7.2), and the
1666 -- content field is a SignedData.
1667 -- The eContentType field for the type SignedData is
1668 -- id-pkinit-DHKeyData (1.3.6.1.5.2.3.2), and the
1669 -- eContent field contains the DER encoding of the
1670 -- type KDCDHKeyInfo.
1671 -- KDCDHKeyInfo is defined below.
1675 Tung & Zhu Expires April 22, 2006 [Page 30]
1677 Internet-Draft PKINIT October 2005
1680 serverDHNonce [1] DHNonce OPTIONAL
1681 -- Present if and only if dhKeyExpiration is
1685 KDCDHKeyInfo ::= SEQUENCE {
1686 subjectPublicKey [0] BIT STRING,
1687 -- KDC's DH public key.
1688 -- The DH public key value is encoded as a BIT
1689 -- STRING according to [RFC3279].
1690 nonce [1] INTEGER (0..4294967295),
1691 -- Contains the nonce in the PKAuthenticator of the
1692 -- request if DH keys are NOT reused,
1694 dhKeyExpiration [2] KerberosTime OPTIONAL,
1695 -- Expiration time for KDC's key pair,
1696 -- present if and only if DH keys are reused. If
1697 -- this field is omitted then the serverDHNonce
1698 -- field MUST also be omitted.
1702 ReplyKeyPack ::= SEQUENCE {
1703 replyKey [0] EncryptionKey,
1704 -- Contains the session key used to encrypt the
1705 -- enc-part field in the AS-REP.
1706 asChecksum [1] Checksum,
1707 -- Contains the checksum of the AS-REQ
1708 -- corresponding to the containing AS-REP.
1709 -- The checksum is performed over the type AS-REQ.
1710 -- The protocol key [RFC3961] of the checksum is the
1711 -- replyKey and the key usage number is 6.
1712 -- If the replyKey's enctype is "newer" [RFC4120]
1713 -- [RFC4121], the checksum is the required
1714 -- checksum operation [RFC3961] for that enctype.
1715 -- The client MUST verify this checksum upon receipt
1720 TD-DH-PARAMETERS ::= SEQUENCE OF AlgorithmIdentifier
1721 -- Each AlgorithmIdentifier specifies a set of
1722 -- Diffie-Hellman domain parameters [IEEE1363].
1723 -- This list is in decreasing preference order.
1731 Tung & Zhu Expires April 22, 2006 [Page 31]
1733 Internet-Draft PKINIT October 2005
1736 Appendix B. Test Vectors
1738 Function octetstring2key() is defined in Section 3.2.3.1. This
1739 section describes a few sets of test vectors that would be useful for
1740 implementers of octetstring2key().
1745 Input octet string x is:
1747 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1748 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1749 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1750 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1751 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1752 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1753 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1754 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1755 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1756 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1757 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1758 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1759 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1760 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1761 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1762 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1764 Output of K-truncate() when the key size is 32 octets:
1766 5e e5 0d 67 5c 80 9f e5 9e 4a 77 62 c5 4b 65 83
1767 75 47 ea fb 15 9b d8 cd c7 5f fc a5 91 1e 4c 41
1772 Input octet string x is:
1774 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1775 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1776 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1777 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1778 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1779 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1780 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1781 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1783 Output of K-truncate() when the key size is 32 octets:
1787 Tung & Zhu Expires April 22, 2006 [Page 32]
1789 Internet-Draft PKINIT October 2005
1792 ac f7 70 7c 08 97 3d df db 27 cd 36 14 42 cc fb
1793 a3 55 c8 88 4c b4 72 f3 7d a6 36 d0 7d 56 78 7e
1798 Input octet string x is:
1800 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
1801 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
1802 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
1803 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
1804 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b
1805 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a
1806 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08 09
1807 0a 0b 0c 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
1809 Output of K-truncate() when the key size is 32 octets:
1811 c4 42 da 58 5f cb 80 e4 3b 47 94 6f 25 40 93 e3
1812 73 29 d9 90 01 38 0d b7 83 71 db 3a cf 5c 79 7e
1817 Input octet string x is:
1819 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
1820 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e
1821 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d
1822 0e 0f 10 00 01 02 03 04 05 06 07 08 09 0a 0b 0c
1823 0d 0e 0f 10 00 01 02 03 04 05 06 07 08
1825 Output of K-truncate() when the key size is 32 octets:
1827 00 53 95 3b 84 c8 96 f4 eb 38 5c 3f 2e 75 1c 4a
1828 59 0e d6 ff ad ca 6f f6 4f 47 eb eb 8d 78 0f fc
1831 Appendix C. Miscellaneous Information about Microsoft Windows PKINIT
1834 Earlier revisions of the PKINIT I-D were implemented in various
1835 releases of Microsoft Windows and deployed in fairly large numbers.
1836 To enable the community to better interoperate with systems running
1837 those releases, the following information may be useful.
1839 KDC certificates issued by Windows 2000 Enterprise CAs contain a
1843 Tung & Zhu Expires April 22, 2006 [Page 33]
1845 Internet-Draft PKINIT October 2005
1848 dNSName SAN with the DNS name of the host running the KDC, and the
1849 id-kp-serverAuth EKU [RFC3280].
1851 KDC certificates issued by Windows 2003 Enterprise CAs contain a
1852 dNSName SAN with the DNS name of the host running the KDC, the id-kp-
1853 serverAuth EKU and the id-ms-kp-sc-logon EKU.
1855 It is anticipated that the next release of Windows is already too far
1856 along to allow it to support the issuing KDC certificates with id-
1857 pkinit-san SAN as specified in this RFC. Instead, they will have a
1858 dNSName SAN containing the domain name of the KDC and the intended
1859 purpose of these KDC certificates be restricted by the presence of
1860 the id-pkinit-KPKdc EKU and id-kp-serverAuth EKU.
1862 In addition to checking that the above are present in a KDC
1863 certificate, Windows clients verify that the issuer of the KDC
1864 certificate is one of a set of allowed issuers of such certificates,
1865 so those wishing to issue KDC certificates need to configure their
1866 Windows clients appropriately.
1868 Client certificates accepted by Windows 2000 and Windows 2003 Server
1869 KDCs must contain an id-ms-san-sc-logon-upn (1.3.6.1.4.1.311.20.2.3)
1870 SAN and the id-ms-kp-sc-logon EKU. The id-ms-san-sc-logon-upn SAN
1871 contains a UTF8 encoded string whose value is that of the Directory
1872 Service attribute UserPrincipalName of the client account object, and
1873 the purpose of including the id-ms-san-sc-logon-upn SAN in the client
1874 certificate is to validate the client mapping (in other words, the
1875 client's public key is bound to the account that has this
1876 UserPrincipalName value).
1878 It should be noted that all Microsoft Kerberos realm names are domain
1879 style realm names and strictly in upper case. In addition, the
1880 UserPrincipalName attribute is globally unique in Windows 2000 and
1899 Tung & Zhu Expires April 22, 2006 [Page 34]
1901 Internet-Draft PKINIT October 2005
1907 USC Information Sciences Institute
1908 4676 Admiralty Way Suite 1001
1909 Marina del Rey, CA 90292
1912 Email: brian@isi.edu
1916 Microsoft Corporation
1921 Email: lzhu@microsoft.com
1955 Tung & Zhu Expires April 22, 2006 [Page 35]
1957 Internet-Draft PKINIT October 2005
1960 Intellectual Property Statement
1962 The IETF takes no position regarding the validity or scope of any
1963 Intellectual Property Rights or other rights that might be claimed to
1964 pertain to the implementation or use of the technology described in
1965 this document or the extent to which any license under such rights
1966 might or might not be available; nor does it represent that it has
1967 made any independent effort to identify any such rights. Information
1968 on the procedures with respect to rights in RFC documents can be
1969 found in BCP 78 and BCP 79.
1971 Copies of IPR disclosures made to the IETF Secretariat and any
1972 assurances of licenses to be made available, or the result of an
1973 attempt made to obtain a general license or permission for the use of
1974 such proprietary rights by implementers or users of this
1975 specification can be obtained from the IETF on-line IPR repository at
1976 http://www.ietf.org/ipr.
1978 The IETF invites any interested party to bring to its attention any
1979 copyrights, patents or patent applications, or other proprietary
1980 rights that may cover technology that may be required to implement
1981 this standard. Please address the information to the IETF at
1985 Disclaimer of Validity
1987 This document and the information contained herein are provided on an
1988 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1989 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1990 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1991 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1992 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1993 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1998 Copyright (C) The Internet Society (2005). This document is subject
1999 to the rights, licenses and restrictions contained in BCP 78, and
2000 except as set forth therein, the authors retain all their rights.
2005 Funding for the RFC Editor function is currently provided by the
2011 Tung & Zhu Expires April 22, 2006 [Page 36]
git.samba.org / samba.git / blob