idnits 2.17.1 draft-ietf-krb-wg-anon-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 461. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 467. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC4120, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC4120, updated by this document, for RFC5378 checks: 2002-02-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 11, 2006) is 6407 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3852 (Obsoleted by RFC 5652) ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP L. Zhu 3 Internet-Draft P. Leach 4 Updates: 4120 (if approved) K. Jaganathan 5 Intended status: Standards Track Microsoft Corporation 6 Expires: April 14, 2007 October 11, 2006 8 Anonymity Support for Kerberos 9 draft-ietf-krb-wg-anon-02 11 Status of this Memo 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- 21 Drafts. 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 14, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document defines extensions to the Kerberos protocol for the 43 Kerberos client to authenticate the Kerberos Key Distribution Center 44 and the Kerberos server, without revealing the client's identity. 45 These extensions can be used to secure communication between the 46 anonymous client and the server. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 52 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 5 54 5. GSS-API Implementation Notes . . . . . . . . . . . . . . . . . 7 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 56 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 57 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 58 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 60 Intellectual Property and Copyright Statements . . . . . . . . . . 11 62 1. Introduction 64 In certain situations, the Kerberos [RFC4120] client may wish to 65 authenticate a server and/or protect communications without revealing 66 its own identity. For example, consider an application which 67 provides read access to a research database, and which permits 68 queries by arbitrary requestors. A client of such a service might 69 wish to authenticate the service, to establish trust in the 70 information received from it, but might not wish to disclose its 71 identity to the service for privacy reasons. 73 Extensions to [RFC4120] are specified in this document by which a 74 client can authenticate the KDC and request an anonymous ticket. The 75 client can use the anonymous ticket to authenticate the server and 76 protect subsequent client-server communications. These extensions 77 provide Kerberos with functional equivalence to Transport Layer 78 Security (TLS) [RFC4346]. 80 By using the extensions defined in this specification, the client MAY 81 reveal its identity in its initial request to its own KDC, but it can 82 remain anonymous thereafter to KDCs on the cross-realm authentication 83 path, and to the server with which it communicates. 85 2. Conventions Used in This Document 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 3. Definitions 93 The anonymous Kerberos realm name is a reserved realm name based on 94 [KRBNAM]. The value is the literal "RESERVED:ANONYMOUS". 96 The anonymous Kerberos principal name is a reserved Kerberos 97 principal name based on [KRBNAM]. The value of the name-type field 98 is KRB_NT_RESRVED [KRBNAM], and the value of the name-string field is 99 a sequence of two KerberosString components: "RESERVED", "ANONYMOUS". 101 Note that in this specification, the anonymous principal name and 102 realm are only applicable to the client in Kerberos messages, the 103 server MUST NOT be anonymous in any Kerberos message. 105 The transited field [RFC4120] of a ticket is an anonymous 106 authentication path if the tr-type field of the TransitedEncoding 107 type [RFC4120] is NO-TRANSITED-INFO and the contents field is an 108 empty OCTET STRING. 110 NO-TRANSITED-INFO TBA 112 This means that no information of the authentication path is 113 disclosed. 115 The anonymous ticket flag is defined as bit TBA (with the first bit 116 being bit 0) in the TicketFlags: 118 TicketFlags ::= KerberosFlags 119 -- anonymous(TBA) 120 -- TicketFlags and KerberosFlags are defined in [RFC4120] 122 An anonymous ticket is a ticket that has all of the following 123 properties: 125 o The cname field [RFC4120] contains the anonymous Kerberos 126 principal name. 128 o The crealm field [RFC4120] contains either the client's realm name 129 or the anonymous realm name. 131 o The transited field [RFC4120] can contain either the client's 132 authentication path as described in Section 3.3.3.2 of [RFC4120] 133 or the anonymous authentication path. 135 o The anonymous ticket contains no information that can reveal the 136 client's identity. However the ticket MAY contain the client 137 realm and the realms on the authentication path, and authorization 138 data that MAY provide information related to the client's 139 identity. For example, an anonymous principal that is only 140 identifiable within a particular group of users can be implemented 141 using authorization data and such authorization data, if included 142 in the anonymous ticket, shall disclose the client's membership of 143 that group. 145 o The anonymous ticket flag is set. 147 The request-anonymous KDC option is defined as bit TBA (with the 148 first bit being bit 0) in the KDCOptions: 150 KDCOptions ::= KerberosFlags 151 -- request-anonymous(TBA) 152 -- KDCOptions and KerberosFlags are defined in [RFC4120] 154 4. Protocol Description 156 In order to request an anonymous ticket, the client sets the request- 157 anonymous KDC option in an Authentication Exchange (AS) or Ticket 158 Granting Service (TGS) request [RFC4120]. The client can request an 159 anonymous TGT based on a normal TGT. If the client wishes to 160 authenticate the KDC anonymously, it sets the client name as 161 anonymous in the AS exchange and provides a PA_PK_AS_REQ pre- 162 authentication data [RFC4556] where both the signerInfos field and 163 the certificates field of the SignedData [RFC3852] of PA_PK_AS_REQ 164 are empty. Because the anonymous client does not have an associated 165 asymmetric key pair, the client MUST use the Diffie-Hellman key 166 agreement method by filling in the Diffie-Hellman domain parameters 167 in the clientPublicValue [RFC4556]. 169 If the ticket in the PA-TGS-REQ [RFC4120] of the TGS request is 170 anonymous, or if the client in the AS request is anonymous, the 171 request-anonymous KDC option MUST be set in the request. 173 Upon receiving the AS request with a PA_PK_AS_REQ from the anonymous 174 client, the KDC skips the checks for the client's signature and the 175 client's public key (such as the verification of the binding between 176 the client's public key and the client name), but performs otherwise- 177 applicable checks, and proceeds as normal according to [RFC4556]. 178 For example, the AS MUST check if the client's Diffie-Hellman domain 179 parameters are acceptable. The Diffie-Hellman key agreement method 180 MUST be used and the reply key is derived according to Section 181 3.2.3.1 of [RFC4556]. If the clientPublicValue is not present in the 182 request, the KDC MUST return a KRB-ERROR [RFC4120] with the code 183 KDC_ERR_PUBLIC_KEY_ENCRYPTION_NOT_SUPPORTED [RFC4556] and there is no 184 accompanying e-data. The client that made the anonymous request can 185 authenticate the KDC based on the KDC's signature in the reply. If 186 the KDC does not have an asymmetric key pair, it MAY reply 187 anonymously. In which case, both the signerInfos field and the 188 certificates field of the SignedData [RFC3852] of PA_PK_AS_REP in the 189 reply are empty. The server name in an anonymous reply contains the 190 name of the TGS. Upon receipt of an anonymous KDC reply, the client 191 MUST reject the returned ticket if it can not authenticate the KDC 192 otherwise. 194 The client can use its keys to mutually authenticate with the KDC, 195 and request an anonymous TGT in the AS request. And in that case, 196 the reply key is selected as normal according to Section 3.1.3 of 197 [RFC4120]. 199 For the TGS exchange, the reply key is selected as normal according 200 to Section 3.3.3 of [RFC4120]. 202 When policy allows, the KDC issues an anonymous ticket. Based on 203 local policy, the client realm in the anonymous ticket can be the 204 anonymous realm name or the realm of the KDC. However, in all cases, 205 the client name and the client realm in the EncKDCRepPart of the 206 reply [RFC4120] MUST match with the corresponding client name and the 207 client realm of the anonymous ticket in the reply. The client MUST 208 use the client name and the client realm returned in the 209 EncKDCRepPart in subsequent message exchanges when using the obtained 210 anonymous ticket. 212 During the TGS request, when propagating authorization data, care 213 MUST be taken by the TGS to ensure that the client confidentiality is 214 not violated. The TGS MUST either fail the request or remove 215 authorization data that may reveal the client's identity. An 216 optional authorization element unknown by the TGS MUST be removed if 217 it can be ignored (such as ones enclosed in the AD-IF-RELEVANT 218 structure). The TGS can only strip critical unknown authorization 219 data if the ticket does not convey any rights such as those conveyed 220 by a KDCIssued authorization data element. If a ticket contains a 221 KDCIssued authorization data element, then no other authorization 222 data elements may be removed if they could serve to limit the rights 223 conveyed by the KDCIssued element. Here is a table of the known 224 authorization-data elements, tagged with whether they interfere with 225 client anonymity and recommendations for how to process them: 227 ad-type References Can Breach Confidentiality? 228 ------------------------------------------------------------------ 229 AD-IF-RELEVANT RFC4120 Yes, remove if unknown 230 AD-KDCIssued RFC4120 Yes, fail the request if unknown 231 AD-AND-OR RFC4120 Yes, remove if unknown 232 AD-MANDATORY-FOR-KDC RFC4120 Yes, fail the request if unknown 234 The KDC fills out the transited field of the anonymous ticket in the 235 reply as follows: If the service ticket in a TGS request is an 236 anonymous ticket with a "normal" authentication path, then the 237 authentication path in the reply ticket MUST also contain a "normal" 238 authentication path, the TGS MUST add the name of the previous realm. 239 However, if the service ticket in a TGS request is an anonymous 240 ticket with an anonymous authentication path, then the reply ticket 241 can contain either an anonymous authentication path or a "normal" 242 authentication path, based on local policy of the KDC. Thus a 243 "normal" authentication path in an anonymous ticket can be a partial 244 path, it may not include all the intermediate realms on the 245 authentication path. 247 The KDC fills out the authtime field of the anonymous ticket in the 248 reply as follows: If the anonymous ticket is returned in an AS 249 exchange, the authtime field of the ticket contains the request time. 251 If the anonymous ticket is returned in a TGS exchange, the authtime 252 field contains the authtime of the ticket in the PA-TGS-REQ 253 [RFC4120]. An anonymous ticket can be renewed, and the authtime 254 field of a renewed ticket is the authtime in the anonymous ticket on 255 which the renewed ticket was based. 257 If it is inappropriate to remove an authorization element from the 258 TGS request in order to produce an anonymous ticket, the KDC MUST 259 return an error message with the code KDC_ERR_POLICY [RFC4120]. 261 If the client is anonymous and the KDC does not have a key to encrypt 262 the reply, the KDC MUST return an error message with the code 263 KDC_ERR_NULL_KEY [RFC4120] and there is no accompanying e-data. 265 If a client requires anonymous communication then the client MUST 266 check to make sure that the ticket in the reply is actually anonymous 267 by checking the presence of the anonymous ticket flag. This is 268 because KDCs ignore unknown KDC options. A KDC that does not 269 understand the request-anonymous KDC option will not return an error, 270 but will instead return a normal ticket. 272 The subsequent client and server communications then proceed as 273 described in [RFC4120]. No transited policy checking is needed for 274 the anonymous authentication path. However, transited policy checks 275 defined in Section 2.7 of [RFC4120] would apply to an anonymous 276 ticket that contains a "normal" authentication path. 278 A server accepting an anonymous service ticket may assume that 279 subsequent requests using the same ticket originate from the same 280 client. Requests with different tickets are likely to originate from 281 different clients. 283 Interoperability and backward-compatibility notes: the KDC is given 284 the task of rejecting a request for an anonymous ticket when the 285 anonymous ticket is not acceptable by the server. 287 5. GSS-API Implementation Notes 289 At the GSS-API [RFC2743] level, the use of an anonymous principal by 290 the initiator/client requires the initiator/client to assert the 291 "anonymous" flag when calling GSS_Init_Sec_Context(). 293 GSS-API does not know or define "anonymous credentials", so the 294 (printable) name of the anonymous principal will rarely be used by or 295 relevant for the initiator/client. The printable name is relevant 296 for the acceptor/server when performing an authorization decision 297 based on the name that pops up from GSS_Accept_Sec_Context() upon 298 successful security context establishment. 300 A GSS-API initiator MUST carefully check the resulting context 301 attributes from the initial call to GSS_Init_Sec_Context() when 302 requesting anonymity, because (as in the GSS-API tradition and for 303 backwards compatibility) anonymity is just another optional context 304 attribute. It could be that the mechanism doesn't recognize the 305 attribute at all or that anonymity is not available for some other 306 reasons -- and in that case the initiator must NOT send the initial 307 security context token to the acceptor, because it will likely reveal 308 the initiators identity to the acceptor, something that can rarely be 309 "un-done". 311 GSS-API defines the name_type GSS_C_NT_ANONYMOUS [RFC2743] to 312 represent the anonymous identity. In addition, Section 2.1.1 of 313 [RFC1964] defines the single string representation of a Kerberos 314 principal name with the name_type GSS_KRB5_NT_PRINCIPAL_NAME. For 315 the anonymous principals, the name component within the exportable 316 name as defined in Section 2.1.3 of [RFC1964] MUST signify the realm 317 name according to Section 2.1.1 of [RFC1964]. Note that in this 318 specification only the client/initiator can be anonymous. 320 Portable initiators are RECOMMENDED to use default credentials 321 whenever possible, and request anonymity only through the input 322 anon_req_flag [RFC2743] to GSS_Init_Sec_Context(). 324 6. Security Considerations 326 Since KDCs ignore unknown options [RFC4120], a client requiring 327 anonymous communication needs to make sure that the ticket is 328 actually anonymous. This is because a KDC that that does not 329 understand the anonymous option would not return an anonymous ticket. 331 By using the mechanism defined in this specification, the client does 332 not reveal its identity to the server but its identity may be 333 revealed to the KDC of the server principal (when the server 334 principal is in a different realm than that of the client), and any 335 KDC on the cross-realm authentication path. The Kerberos client MUST 336 verify the ticket being used is indeed anonymous before communicating 337 with the server, otherwise the client's identity may be revealed 338 unintentionally. 340 In cases where specific server principals must not have access to the 341 client's identity (for example, an anonymous poll service), the KDC 342 can define server principal specific policy that insure any normal 343 service ticket can NEVER be issued to any of these server principals. 345 If the KDC that issued an anonymous ticket were to maintain records 346 of the association of identities to an anonymous ticket, then someone 347 obtaining such records could breach the anonymity. Additionally, the 348 implementations of most (for now all) KDC's respond to requests at 349 the time that they are received. Traffic analysis on the connection 350 to the KDC will allow an attacker to match client identities to 351 anonymous tickets issued. Because there are plaintext parts of the 352 tickets that are exposed on the wire, such matching by a third party 353 observer is relatively straightforward. 355 7. Acknowledgements 357 Clifford Neuman contributed the core notions of this document. 359 Martin Rex wrote the text for GSS-API considerations. 361 Nicolas Williams reviewed the GSS-API considerations section and 362 suggested ideas for improvements. 364 Sam Hartman and Nicolas Williams were great champions of this work. 366 In addition, the following individuals made significant 367 contributions: Jeffery Altman, Tom Yu, Chaskiel M Grundman, Love 368 Hoernquist Aestrand, and Jeffery Hutzelman. 370 8. IANA Considerations 372 Section 3 defines the anonymous Kerberos name and the anonymous 373 Kerberos realm based on [KRBNAM]. The IANA registry for [KRBNAM] 374 need to be updated to add references to this document. 376 9. Normative References 378 [KRBNAM] Zhu, L., "Additonal Kerberos Naming Contraints", 379 draft-ietf-krb-wg-naming, work in progress. 381 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 382 RFC 1964, June 1996. 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, March 1997. 387 [RFC2743] Linn, J., "Generic Security Service Application Program 388 Interface Version 2, Update 1", RFC 2743, January 2000. 390 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 391 RFC 3852, July 2004. 393 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 394 Kerberos Network Authentication Service (V5)", RFC 4120, 395 July 2005. 397 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 398 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 400 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 401 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 403 Authors' Addresses 405 Larry Zhu 406 Microsoft Corporation 407 One Microsoft Way 408 Redmond, WA 98052 409 US 411 Email: lzhu@microsoft.com 413 Paul Leach 414 Microsoft Corporation 415 One Microsoft Way 416 Redmond, WA 98052 417 US 419 Email: paulle@microsoft.com 421 Karthik Jaganathan 422 Microsoft Corporation 423 One Microsoft Way 424 Redmond, WA 98052 425 US 427 Email: karthikj@microsoft.com 429 Full Copyright Statement 431 Copyright (C) The Internet Society (2006). 433 This document is subject to the rights, licenses and restrictions 434 contained in BCP 78, and except as set forth therein, the authors 435 retain all their rights. 437 This document and the information contained herein are provided on an 438 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 439 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 440 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 441 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 442 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 443 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 445 Intellectual Property 447 The IETF takes no position regarding the validity or scope of any 448 Intellectual Property Rights or other rights that might be claimed to 449 pertain to the implementation or use of the technology described in 450 this document or the extent to which any license under such rights 451 might or might not be available; nor does it represent that it has 452 made any independent effort to identify any such rights. Information 453 on the procedures with respect to rights in RFC documents can be 454 found in BCP 78 and BCP 79. 456 Copies of IPR disclosures made to the IETF Secretariat and any 457 assurances of licenses to be made available, or the result of an 458 attempt made to obtain a general license or permission for the use of 459 such proprietary rights by implementers or users of this 460 specification can be obtained from the IETF on-line IPR repository at 461 http://www.ietf.org/ipr. 463 The IETF invites any interested party to bring to its attention any 464 copyrights, patents or patent applications, or other proprietary 465 rights that may cover technology that may be required to implement 466 this standard. Please address the information to the IETF at 467 ietf-ipr@ietf.org. 469 Acknowledgment 471 Funding for the RFC Editor function is provided by the IETF 472 Administrative Support Activity (IASA).