idnits 2.17.1 draft-hotz-kx509-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2012) is 4281 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 181 -- Looks like a reference, but probably isn't: '1' on line 182 -- Looks like a reference, but probably isn't: '2' on line 183 -- Looks like a reference, but probably isn't: '3' on line 184 == Missing Reference: 'HEX DUMP' is mentioned on line 572, but not defined ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Hotz 3 Internet-Draft Jet Propulsion Laboratory, 4 Intended status: Informational California Institute of 5 Expires: January 10, 2013 Technology 6 R. Allbery 7 Stanford University 8 July 9, 2012 10 KX509 Kerberized Certificate Issuance Protocol in Use in 2012 11 draft-hotz-kx509-06.txt 13 Abstract 15 This document describes a protocol, called kx509, for using Kerberos 16 tickets to acquire X.509 certificates. These certificates may be 17 used for many of the same purposes as X.509 certificates acquired by 18 other means, but if a Kerberos infrastructure already exists then the 19 overhead of using kx509 may be much less. 21 While not standardized, this protocol is already in use at several 22 large organizations, and certificates issued with this protocol are 23 recognized by the International Grid Trust Federation. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 10, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Protocol Data . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Request Packet . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Reply Packet . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 7 65 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 71 Appendix A. Certificate Cacheing and Deployment Considerations . 12 72 Appendix B. Historic Extensions . . . . . . . . . . . . . . . . . 12 73 Appendix C. Example Exchange . . . . . . . . . . . . . . . . . . 13 74 Appendix D. Change History . . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 The two primary ways of providing cryptographically secure 80 identification on the Internet are Kerberos tickets [RFC4120], and 81 X.509 [RFC5280] and [X.509] certificates. 83 In practical IT infrastructure where both are in use, it's highly 84 desirable to deploy their support in a way which guarantees they both 85 authoritatively refer to the same entities. There is already a 86 widely-adopted standard for using X.509 certificates to acquire 87 corresponding Kerberos tickets called PKINIT [RFC4556]. This 88 document describes the kx509 protocol for supporting the symmetric 89 operation of acquiring X.509 certificates using Kerberos tickets. 91 Preparing and reviewing this document exposed a number of issues 92 which are discussed in the security considerations. Unfortunately, 93 some of them can only be addressed with an incompatible upgrade to 94 this protocol. The IETF's Kerberos working group has an expected 95 work item to address these issues. 97 The International Grid Trust Federation [IGTF] supports the use of 98 Short Lived Credential Services [SLCS] as a means to authenticate for 99 resource usage based on other, native identity stores which an 100 organization maintains. X.509 certificates issued using the kx509 101 protocol based on a Kerberos identity is one of the recognized 102 Credential Services. The certificate profile for that use is outside 103 the scope of this RFC, but is described in [GRID-prof]. 105 In normal operation kx509 can be used after a Kerberos ticket- 106 granting-ticket (TGT) is acquired, which is most likely during user 107 login. First, the client generates a RSA public/private key-pair. 108 Next, using the Kerberos ticket-granting-ticket, it acquires a 109 Kerberos service ticket for the KCA (Kerberized Certificate 110 Authority), and uses this to send the public half of its key-pair. 111 The KCA will decrypt the service ticket, verify the integrity of the 112 incoming packet, determine the identity of the user, and use the 113 session key to send back a corresponding X.509 certificate. 115 1.1. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 2. Protocol Data 123 The protocol consists of a single request/reply exchange using UDP. 125 Both the request and the reply packet begin with four bytes of 126 version ID information, followed by a DER encoded ASN.1 message. The 127 first two bytes of the version ID are reserved. They MUST be set to 128 zero when sent, and SHOULD be ignored when received. The third and 129 fourth bytes are the major and minor version numbers, respectively. 130 The version of the protocol described in this document is designated 131 2.0, so the first four bytes of the packet are 0, 0, 2, 0. 133 Incompatible variations of this protocol MUST use a different major 134 version number. 136 2.1. Request Packet 138 The request consists of a version ID, followed by a DER encoded ASN.1 139 message containing a Kerberos AP_REQ, integrity check data on the 140 request, and public key generated by the client. The ASN.1 encoding 141 is: 143 KX509Request ::= SEQUENCE { 144 ap-req OCTET STRING, 145 pk-hash OCTET STRING, 146 pk-key OCTET STRING 147 } 149 The ap-req is as described in [RFC4120] Section 5.5.1. 151 The pk-hash is HMAC using SHA-1 as the underlying hash. All 160 bits 152 are sent. The key used is the Kerberos session key. The data to be 153 hashed is the concatenation of 155 o 4-byte version ID at the beginning of the packet. 157 o OCTET STRING of the ap-req. 159 o OCTET STRING of the pk-key. 161 The pk-key contains a public key. This key and its corresponding 162 private key are generated by the client before contacting the server. 163 Implementations of this protocol MUST support RSA keys, in which case 164 the key is a DER encoded RSAPublicKey as defined in [RFC3447], 165 section A.1.1, and then stored in this octet string in the request. 166 Its encoding as an OCTET STRING starts with the 0x30 byte sequence at 167 the beginning of a DER encoded RSAPublicKey. Use of other public-key 168 types is not defined. 170 Appendix C shows an example request packet. 172 2.2. Reply Packet 174 The reply consists of a version ID, followed by a DER encoded ASN.1 175 message containing an error code, and an optional authentication 176 hash, optional certificate, and optional error text. The service 177 SHOULD return replies of the same version as the request where 178 possible. 180 KX509Response ::= SEQUENCE { 181 error-code[0] INTEGER DEFAULT 0, 182 hash[1] OCTET STRING OPTIONAL, 183 certificate[2] OCTET STRING OPTIONAL, 184 e-text[3] VisibleString OPTIONAL 185 } 187 Although the format of the reply contains independently optional 188 objects, the server MUST only generate replies with one of the 189 following allowed combinations. 191 +------------+------+-------------+--------+ 192 | | hash | certificate | | 193 | error-code | hash | | e-text | 194 | error-code | | | e-text | 195 +------------+------+-------------+--------+ 197 The first case is returned when the server successfully generates a 198 certificate for the user. The certificate is a DER encoded 199 Certificate as defined in [RFC5280] Section A, page 116. Its 200 encoding as an OCTET STRING starts with the 0x30 byte sequence that 201 is at the beginning of a DER encoded Certificate. 203 The second case is returned when the server successfully 204 authenticates the user and their key, but is unable for some other 205 reason to generate a certificate. 207 The third case MAY be returned if the server is unable to 208 successfully authenticate the user and intends to return some 209 unauthenticated information to the client. 211 The hash on a response is computed using SHA-1 HMAC as for the 212 request. 214 The data that is hashed is the concatenation of the following things: 216 o 4-byte version ID at the beginning of the packet. 218 o DER representation of the error-code exclusive of the tag and 219 length, if it is present. 221 o OCTET STRING of the certificate, if it is present. 223 o VisibleString representation of the e-text exclusive of the tag 224 and length, if it is present. 226 In other words, the hash is computed on the data in the fields which 227 are present exclusive of the overall ASN.1 wrapping. 229 The e-text MAY be translated into other character sets for display 230 purposes, but the hash is computed on the e-text in its VisibleString 231 representation. If the e-text contains NUL characters, the client 232 MAY ignore any part of the error message after the first NUL 233 character for display purposes. 235 As implied by the above table, if the reply does not contain a 236 certificate it MUST contain an error message and a non-zero error 237 code. Conversely, if a certificate is returned then the error code 238 MUST be zero. The server SHOULD use the DEFAULT encoding for a zero 239 error-code value by omitting any explicit error-code from the reply. 241 The defined error codes are as follows: 243 +------------+-----------------------------+------------------------+ 244 | error-code | Condition | Example | 245 +------------+-----------------------------+------------------------+ 246 | 1 | Permanent problem with | Incompatible version | 247 | | client request | | 248 | 2 | Solvable problem with | Expired Kerberos | 249 | | client request | credentials | 250 | 3 | Temporary problem with | Packet loss | 251 | | client request | | 252 | 4 | Permanent problem with the | Internal | 253 | | server | misconfiguration | 254 | 5 | Temporary problem with the | Server overloaded | 255 | | server | | 256 +------------+-----------------------------+------------------------+ 258 If a client error is returned, the client SHOULD NOT retry the 259 request unless some remedial action is first taken, although if 260 error-code 3 is returned, the client MAY retry with other servers 261 before giving up. 263 If a server error is returned, it is RECOMMENDED that the client 264 retry the request with a different server if one is known. 266 Since all KCAs serving a Kerberos realm are intended to be 267 equivalent, in accordance with [RFC5280] Section 4.1.2.2, the 268 certificates returned from different KCAs serving the same Kerberos 269 realm MUST NOT contain duplicate serial numbers. 271 This protocol and document do not address certificate verification or 272 path construction. There are no provisions for returning any 273 additional certificates which might be needed. Any application using 274 a returned certificate must be configured independently to address 275 these issues. An incompatible upgrade to this protocol will provide 276 options to address this issue. 278 The returned certificate MUST identify the Kerberos client principal 279 from the ap-req in the original KX509Request in the subject of the 280 cert, or in a subjectAltName extension. The identification MUST be 281 unique within the organization's deployed infrastructure. It is 282 RECOMMENDED that a subjectAltName extension be included of type id- 283 pkinit-san as described in [RFC4556] Section 3.2.2. Note that the 284 id-pkinit-san is simply a standard representation of a Kerberos 285 principal, and has no other implications with respect to PKINIT. 287 Other extensions MAY be added according to local policy. 289 Appendix C shows an example reply packet. 291 3. Protocol Operation 293 Absent errors, the protocol consists of a single request, sent via 294 UDP, and a single reply, also sent via UDP. 296 There is no special provision for requests or replies which exceed 297 the allowable size of a UDP packet. Also some implementations have 298 imposed hard size limits which are smaller than a typical UDP MTU, 299 and will limit the use of extensions and the supportable key size. 300 Even without hard limits, if the request or reply exceeds the MTU 301 size of a UDP packet for the infrastructure in use, then the 302 reliability of the exchange will decrease significantly. 304 For "normal" Kerberos ap-req structures, and "normal" X.509 305 certificates, this is unlikely unless the Kerberos service ticket 306 contains large amounts of authorization data. For this reason, it is 307 RECOMMENDED that service tickets for the KCA be issued without 308 authorization data. If the KCA performs authorization, it should do 309 so by other means. 311 Before constructing the request, the client must know the canonical 312 name(s) and port(s) of the server(s) to contact. It MAY determine 313 them by looking up the service's SRV record as described in[RFC2782]. 314 The entry to be used is _kca._udp._realm_, where _realm_ is the 315 Kerberos realm, used as part of the DNS name. 317 The client has to acquire a service ticket in order to construct the 318 ap-req for the service. Conventionally, the Kerberos service 319 principal name to use for this service has a first component of 320 "kca_service". Absent local configuration or other external 321 knowledge of the correct principal to use, the second and final 322 component is conventionally the canonical name of the KCA server 323 being contacted, and the realm of the principal is determined 324 following normal Kerberos domain to realm mapping conventions, as 325 discussed in [RFC4120] Section 1.3. 327 When the server receives a request, it MUST verify the following 328 properties of the request before issuing a certificate: 330 o The AP-REQ can be decoded and is not expired. 332 o If the request uses cross-realm authentication, then it satisfies 333 the requirements of local policy and [RFC4120] Sections 1.2 and 334 2.7. 336 o The request's hash is valid. 338 The server SHOULD make other sanity checks, such as a minimum public 339 key length, to the extent feasible. 341 The server MAY decline to respond to an erroneous request. If it 342 does not receive a response a client MAY retry its request, but the 343 client SHOULD wait at least one second before doing so. 345 The client MUST verify any hash in the reply, and MUST NOT use any 346 certificate in a reply whose hash does not verify. The client MAY 347 display the e-text if the hash is absent or does not verify, but 348 SHOULD indicate the message is not authenticated. 350 4. Acknowledgements 352 The original version of kx509 was implemented using Kerberos 4 at the 353 University of Michigan, and was nicely documented in [KX509]. Many 354 thanks to them for their original work, as well as the subsequent 355 updates. 357 While developing this document important corrections and comments 358 were provided by Jeffrey Altman, and Love Hornquist Astrand. The 359 following people also provided many helpful comments and corrections: 360 Doug Engert, Jeffrey Hutzelman, Sam Hartman, Timothy J. Miller, 361 Chaskiel Grundman, and Jim Schaad. Alan Sill provided the references 362 to the International Grid Trust Federation and its acceptable 363 credential services. Example network traffic was provided by Doug 364 Engert, Marcus Watts, Matt Crawford, and Chaskiel Grundman from their 365 deployments, and was extremely useful for verifying the reality of 366 this specification. 368 5. IANA Considerations 370 This service is conventionally run on UDP port 9878. IANA is 371 requested to register that port in the Service Name and Transport 372 Port Number Registry as follows: 374 RFC Editor Note: Change RFC XXXX to the assigned RFC number on 375 publication and remove this note. 377 Service Name: kca-service 378 Transport Protocol: UDP 379 Assignee: IESG 380 Contact: IETF Chair 381 Description: The KX509 Kerberized Certificate Issuance 382 Protocol in Use in 2012 383 Reference: RFC XXXX 384 Port Number: 9878 385 Assignment Notes: Historically, this service has been referred to 386 as "kca_service", but this service name does 387 not meet the registry requirements. 389 The GSSAPI/Kerberos/SASL service name currently in use for this 390 protocol is "kca_service". This does not meet the naming 391 requirements for IANA's GSSAPI/Kerberos/SASL service name registry, 392 so no registration is requested. The conflict between the 393 conventional service name and the registry rules is expected to be 394 addressed in a future version of this protocol. Appropriate 395 registrations will be requested at that time. 397 6. Security Considerations 399 The only encrypted information in the protocol is that used by 400 Kerberos itself. The considerations for any Kerberized service apply 401 here. 403 The public key in the request is sent in the clear, and without any 404 guarantees that the requester actually possesses the corresponding 405 private key. Therefore the only appropriate uses of the returned 406 certificate are those where the identity of the requester is 407 unimportant, or the subsequent use independently guarantees that the 408 user possesses the private key. This issue is expected to be 409 addressed in a future version of this protocol. 411 For example, if the kx509-issued certificate is used for a digital 412 signature in a way which does not independently demonstrate proof-of- 413 possession of the private key, then an eavesdropper could request 414 their own valid certificate via kx509 and claim to have originated 415 material signed by the legitimate, original requester. [RFC4211], 416 Appendix C contains a more detailed discussion of why proof-of- 417 possession is important. 419 An example which should be safe is initial client authentication with 420 TLS [RFC5246] connections. If a client certificate is used then a 421 Certificate Verify message (Section 7.4.8 of that RFC) is added to 422 the handshake exchange. It includes a signature of the handshake 423 messages to that point. Those messages depend on data known only to 424 the client and server ends of the specific connection, so computing 425 the signature proves possession of the private key. This application 426 was the original intended use case for kx509. 428 Some information, such as the public key and certificate, is 429 transmitted in the clear but (as the name implies) were generally 430 intended to be publicly available. However their visibility could 431 still raise privacy concerns. The hash is used to protect their 432 integrity. 434 The policies for issuing Kerberos tickets and X.509 certificates are 435 usually expressed very differently. An implementation of this 436 protocol should not provide a mechanism for bypassing ticket or 437 certificate policies. 439 In particular, if the issued certificate can be used with PKINIT, 440 this authentication loop SHOULD NOT bypass policy limits for either 441 X.509 certificates or Kerberos tickets. 443 X.509 certificates are usually issued with considerably longer 444 validity times than Kerberos tickets. Care should be taken that the 445 issued certificate is not valid for longer than the intended policy 446 should allow. Note that [RFC4556] Section 3.2.3.1 REQUIRES that the 447 lifetime of an issued ticket not exceed the lifetime of the 448 predecessor certificate. By analogy it is RECOMMENDED that the 449 lifetime of an issued certificate not exceed the lifetime of the 450 predecessor Kerberos ticket unless the implications with respect to 451 local policy and supporting infrastructure are clearly understood and 452 allow it. 454 7. References 455 7.1. Normative References 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, March 1997. 460 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 461 Standards (PKCS) #1: RSA Cryptography Specifications 462 Version 2.1", RFC 3447, February 2003. 464 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 465 Kerberos Network Authentication Service (V5)", RFC 4120, 466 July 2005. 468 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 469 Housley, R., and W. Polk, "Internet X.509 Public Key 470 Infrastructure Certificate and Certificate Revocation List 471 (CRL) Profile", RFC 5280, May 2008. 473 7.2. Informative References 475 [GRID-prof] 476 "GRID Certificate Profile", March 2008, 477 . 479 [IGTF] "The International Grid Trust Federation", 480 . 482 [KX509] Doster, W., Watts, M., and D. Hyde, "The KX509 Protocol", 483 September 2001, . 486 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 487 specifying the location of services (DNS SRV)", RFC 2782, 488 February 2000. 490 [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure 491 Certificate Request Message Format (CRMF)", RFC 4211, 492 September 2005. 494 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 495 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 497 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 498 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 500 [SLCS] "Short Lived Credential Services", February 2009, 501 . 503 [X.509] International Telecommunications Union, "Recommendation 504 X.509: The Directory: Public-key and attribute certificate 505 framework", November 2008. 507 Appendix A. Certificate Cacheing and Deployment Considerations 509 As noted in the Security Considerations section, the functional 510 lifetime of the acquired X.509 certificate should usually match the 511 lifetime of its predecessor Kerberos ticket. Therefore, it is likely 512 that X.509 certificates issued with this protocol should be deleted 513 when the supporting Kerberos tickets are deleted. That makes the 514 Kerberos ticket cache a reasonable location to store the certificate 515 (and its private key). 517 On the other hand applications, such as web browsers, probably expect 518 certificates in different stores. 520 A widely used solution to this dichotomy is to implement a PKCS11 521 library which supports the KX509-acquired credentials. The 522 credentials remain stored in the Kerberos credentials cache, but full 523 PKI functionality is still available via a standard interface for PKI 524 credentials. 526 Appendix B. Historic Extensions 528 This appendix documents extensions to the kx509 protocol which are 529 either no longer in use, or are expected to be dropped. 531 A subjectAltName othername extension of type kcaAuthRealm (OID value 532 1.3.6.1.4.1.250.42.1) is frequently used to include the client's 533 realm as an ASN.1 octet string. 535 The Microsoft-defined userPrincipalName has frequently been used for 536 the same purpose as the id-pkinit-san. 538 The historic implementations of this protocol included provisions for 539 DSA keys in place of RSA. DSA does not appear to be in use. A 540 future version of this protocol will use a standard certificate 541 request structure which will provide algorithm agility. 543 The historic implementations of this protocol allowed an optional 544 client-version field (at the end of the request) of type 545 VisibleString. If present, the KCA copied it into the issued 546 certificate as an extension with the OID 1.3.6.1.4.1.250.42.2. This 547 feature does not appear to be in use. 549 Appendix C. Example Exchange 551 The request and reply are from the same exchange. The Ethernet, IP, 552 and UDP headers, and the 4-byte version string at the beginning of 553 the request and reply packets are all omitted. Only the ASN.1- 554 encoded portions are shown. 556 0:d=0 hl=4 l= 678 cons: SEQUENCE 557 4:d=1 hl=4 l= 509 prim: OCTET STRING 558 [HEX DUMP]:6E8201F9308201F5A003... (ap-req) 559 517:d=1 hl=2 l= 20 prim: OCTET STRING 560 [HEX DUMP]:ECFF1C922300D0E9DD02... (pk-hash) 561 539:d=1 hl=3 l= 140 prim: OCTET STRING 562 [HEX DUMP]:30818902818100B70F46... (pk-key) 564 Request Packet ASN.1 Decode 566 0:d=0 hl=4 l= 870 cons: SEQUENCE 567 4:d=1 hl=2 l= 22 cons: cont [ 1 ] 568 6:d=2 hl=2 l= 20 prim: OCTET STRING 569 [HEX DUMP]:F3A844834C26D843B6FD... (hash) 570 28:d=1 hl=4 l= 842 cons: cont [ 2 ] 571 32:d=2 hl=4 l= 838 prim: OCTET STRING 572 [HEX DUMP]:308203423082022AA003... (certificate) 574 Reply Packet ASN.1 Decode 576 Appendix D. Change History 578 RFC Editor Note: Delete this appendix before final publication. 580 Changes from Draft -04 to Draft -05: 582 1. The title, a word in the abstract, and the reference to the IETF 583 Kerberos working group were changed to make it clearer that this 584 is not a standards-track document. 586 2. Added Appendix C, to clarify the ASN.1 encoding, and specify the 587 byte string that begins the ASN.1 OCTET STRING encoding of 588 certificates. 590 3. Removed the request for IANA registration of the GSSAPI/Kerberos/ 591 SASL name, since the service name registry does not allow the 592 form of name actually in use. Add an IANA registration request 593 for the conventional port number. 595 Changes from Draft -03 to Draft -04: 597 1. The list of possible issues was deleted. Either appropriate 598 comments have been added to the text, or the issue is mentioned 599 as something to be addressed in an incompatible future version of 600 this protocol. 602 2. Clarified the hash computations in sections 2.1 and 2.2. 604 3. Clarified the procedure for determining the Kerberos principal of 605 the KCA in section 3. 607 4. Clarified the discussion of the "proof-of-possession" issue in 608 the Security Considerations with appropriate references. 610 Changes from Draft -02 to Draft -03: 612 1. The abstract was expanded. 614 2. Additional information was provided on traditional UDP size 615 restrictions and their effect on reliability and key sizes in 616 section 3. 618 3. The updates to the security considerations for digital signature 619 usage were incomplete, and have been rewritten. 621 4. Information on an optional client version feature (which does not 622 appear to be actually in use) was added to the request ASN.1, and 623 Appendix B, and the title of the appendix changed. 625 5. As before some minor changes to wording were made for clarity, 626 but are not believed to have changed the meaning. 628 Changes from Draft -01 to Draft -02: 630 1. The retry behavior was made slightly less specific. 632 2. The traditionally used SAN extensions were moved to a new 633 appendix, leaving only the id-pkinit-san as the RECOMMENDED SAN. 635 3. The absolute prohibition against digital signatures in the 636 Security Considerations section was relaxed since there are 637 legitimate situations where a signature based on the KX509 638 certificate is still useful. (E.g. integrity protection where 639 the actual signing identity is not important.) 641 4. Reference to TAGPMA in the abstract was replaced with a reference 642 to its parent, the International Grid Trust Federation, and more 643 detailed informative references were expanded in the 644 Introduction. 646 5. Assorted other wording changes were made for clarity, but are not 647 believed to have changed the meaning. 649 Authors' Addresses 651 Henry B. Hotz 652 Jet Propulsion Laboratory, California Institute of Technology 653 4800 Oak Grove Dr. 654 Pasadena, CA 91109 655 US 657 Phone: +01 818 354-4880 658 Email: hotz@jpl.nasa.gov 660 Russ Allbery 661 Stanford University 662 P.O. Box 20066 663 Stanford, CA 94309 664 US 666 Email: rra@stanford.edu 667 URI: http://www.eyrie.org/~eagle/