idnits 2.17.1 draft-williams-kitten-krb5-pkcross-02.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 (August 13, 2013) is 3909 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) ** Downref: Normative reference to an Informational RFC: RFC 2986 ** Downref: Normative reference to an Informational RFC: RFC 6717 == Outdated reference: A later version (-02) exists of draft-williams-kitten-generic-naming-attributes-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.williams-kitten-generic-naming-attributes' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Williams 3 Internet-Draft Cryptonector 4 Intended status: Standards Track August 13, 2013 5 Expires: February 14, 2014 7 Public Key-Based Kerberos Cross Realm Path Traversal Protocol Using 8 Kerberized Certification Authorities (kx509) and PKINIT 9 draft-williams-kitten-krb5-pkcross-02 11 Abstract 13 This document specifies a protocol for obtaining cross-realm Kerberos 14 tickets using existing, related protocols: kerberized certification 15 authorities (kx509) and public key cryptography initial 16 authentication in Kerberos (PKINIT). The resulting protocol has a 17 number of desirable security properties, including privacy protection 18 for the user relative to their home realm's infrastructure, as well a 19 support for leap-of-faith trust establishment, and automated cross- 20 realm keying. This protocol allows Kerberos to scale to large 21 numbers of realms. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 14, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Conventions used in this document . . . . . . . . . . . . 3 59 2. The Protocol . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Exchange of Long-Term Cross-Realm Symmetric Keys . . . . . 4 61 3. Security Properties . . . . . . . . . . . . . . . . . . . 6 62 3.1. Automated Cross-Realm Keying . . . . . . . . . . . . . . . 6 63 3.2. Privacy Protection relative to home realm . . . . . . . . 6 64 3.3. Leap-of-Faith (LoF) / Trust-On-First-Use (TOFU) . . . . . 6 65 3.3.1. Requirements and Recommendations for LoF/TOFU 66 Authentication . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Using DANE (DNSSEC) for Realm Certificate Validation . . . 8 68 5. Application Programming Interface Considerations . . . . . 9 69 5.1. API Considerations for LoF/TOFU Authentication . . . . . . 9 70 5.2. GSS-API Naming Considerations . . . . . . . . . . . . . . 9 71 6. Security Considerations . . . . . . . . . . . . . . . . . 10 72 6.1. Loss of Cross-Realm Principal Trust Establishment 73 Information . . . . . . . . . . . . . . . . . . . . . . . 10 74 6.2. Security Considerations for LoF/TOFU . . . . . . . . . . . 10 75 6.3. On the Need for a Common Transit Path Policy Language . . 11 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 12 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . 13 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 80 Author's Address . . . . . . . . . . . . . . . . . . . . . 14 82 1. Introduction 84 Kerberos [RFC4120] supports meshes of many realms. The individual 85 relationships between realms must be manually keyed, usually with 86 keys derived from passwords. These keys are very difficult to 87 rollover, and when they are changed the result is often outages -- 88 controlled outages where foreseen, but outages nonetheless. This 89 method of cross-realm keying does not scale, and has very poor 90 security properties. We seek to remediate this. 92 Many years ago there was a proposal for exchanging cross-realm keys 93 using a public key infrastructure (PKI) [RFC5280]; that proposal went 94 by the name "PKCROSS". We appropriate that long-dead proposal's 95 name, but the protocol specified here is very different from the 96 original proposal. 98 1.1. Conventions used in this document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. The Protocol 106 A Kerberos client in with a ticket-granting ticket (TGT) for any one 107 source realm (usually but not necessarily the client's own realm) 108 wishing to acquire a TGT for a destination realm may use this 109 protocol instead of the traditional cross-realm ticket-granting 110 service (TGS) exchanges as follows: 112 1. Generate private key to a public key cryptosystem; 114 2. Generate a certificate signing request (CSR) [RFC2986], such that 115 the resulting certificate has an id-pkinit-san subject 116 alternative name (SAN) corresponding to the client's principal 117 name and realm; 119 3. Request a certificate from the kx509 [RFC6717] service run by the 120 source realm; 122 4. Request a TGT from the destination realm using PKINIT [RFC4556]. 124 If the destination realm issues the requested Ticket then it SHOULD 125 include the client's certificate in an AD-CLIENT-CERTIFICATE 126 authorization-data element, and it MUST do so if it does not validate 127 the client's certificate to an acceptable trust anchor. 129 The destination realm MUST NOT set the TRANSIT-POLICY-CHECKED flag on 130 the tickets they issue to clients whose foreign realm certificates 131 are not validated by the KDC. Destination realm administrators may 132 configure their realms to know specific foreign realm clients' 133 certificates. 135 The destination MUST include the trust path of the client's 136 certificate, if validated, in the 'transited' field of the issued 137 Ticket, using a mapping of the issuer names to the X.500 realm naming 138 style [XXX must specify this mapping; hopefully it can be the 139 identity function or close enough]. 141 2.1. Exchange of Long-Term Cross-Realm Symmetric Keys 143 When the client principal is a TGS principal and its PKINIT AS-REQ 144 protocol data unit (PDU) has the USE-SESSION-KEY-AS-REALM-KEY 145 KDCOptions flag set then the client is requesting that the session 146 key of the ticket issued by the destination realm become the long- 147 term key for the corresponding krbtgt/DESTINATION@SOURCE principal. 148 The destination realm MUST validate the client principal's 149 certificate, building a trust path if need be, and validating it to a 150 trust anchor. The source and destination realm MAY have previously 151 exchange fingerprints of their respective key distribution service 152 (KDC) public keys and/or certificates and/or the source realm's kx509 153 root or intermediate certification authority (CA), and such 154 previously exchanged material, if any, MUST be used for certificate 155 trust validation. 157 Realm administrators should use the procedure to setup symmetric 158 cross-realm keys as necessary to save clients from having to 159 frequently use kx509 and PKINIT as described in the preceding 160 section. 162 Where public key infrastructure (PKI) exists allowing this to happen 163 automatically, realms' KDCs MAY be configured to automatically key 164 cross-realm principals for any realms that their source realms' 165 clients request cross-realm TGTs for, but note that this presents a 166 denial of service (DoS) opportunity to the source realm's clients. 167 Source realm KDCs SHOULD only do this when a) they are configured to 168 do so, b) the requesting client principal is in the same realm, c) 169 the KDC has not spent too much effort recently providing this service 170 (i.e., KDCs should throttle attempts to establish symmetric cross- 171 realm keys in this manner), and d) up to some maximum number of 172 cross-realm principals. 174 3. Security Properties 176 The proposed PKCROSS protocol has several useful properties described 177 below. 179 3.1. Automated Cross-Realm Keying 181 No more manual keying of cross-realm principals via exchanging 182 passwords on a telephone call (or similar). 184 3.2. Privacy Protection relative to home realm 186 This protocol protects the privacy of client principals vis-a-vis 187 their home realms: client principals' home realms need not know what 188 destination realms the clients are speaking to because client 189 principals need not ask their home realms. 191 This feature is generally and naturally available in PKI, and as this 192 protocol is based on a kerberized certification authority, this 193 protocol inherits this privacy feature from PKI. 195 3.3. Leap-of-Faith (LoF) / Trust-On-First-Use (TOFU) 197 Clients need not validate the certificate trust path of destination 198 realms. When they do not, the services used through those 199 destination realms are as good as anonymous authentication. If the 200 client saves the root or intermediate or end entity certificates of 201 the destination realms that it cannot or does not validate, then the 202 client can check that on future occasions the destination realm's 203 certificate has not changed, and it may warn the user if it has. 204 This quite similar to how clients using the secure shell (SSH) 205 protocol [RFC4251] handle server authentication, and is commonly 206 known as "leap-of-faith" (LoF) or trust-on-first-use (TOFU). The 207 result is pseudonymous authentication. 209 Destination services too may apply apply LoF/TOFU: by not validating 210 the transit path of the client (e.g., if it's not in a white-list of 211 realms whose clients must have valid transit paths) and accepting 212 tickets without the TRANSITED-POLICY-CHECKED ticket flag set. The 213 destination service can save the client's certificate, if found in an 214 AD-CLIENT-CERTIFICATE authorization-data element in the client's 215 Ticket, and may use it later to ensure that it is talking to the same 216 client. 218 3.3.1. Requirements and Recommendations for LoF/TOFU Authentication 219 o Implementations MUST NOT use LoF/TOFU to authenticate a target 220 service's realm without the approval of the user or without making 221 it clear that the realm is not fully authenticated (perhaps by 222 replacing the realm's name with a fingerprint of its public key / 223 certificate). 225 o Implementations MAY allow service administrators to establish 226 user-friendly aliases for client principal names that include 227 public key fingerprint material. 229 o Implementations MAY provide a way to automatically learn realm 230 name <-> public key / certificate bindings. Pinning [add 231 reference to HSTS] SHOULD be supported in that case. The user 232 MUST approve of each such mapping. 234 4. Using DANE (DNSSEC) for Realm Certificate Validation 236 [Specify how to use DNS-Based Authentication of Named Entities (DANE) 237 [RFC6698] to authenticate the KDC certificates of realms with domain- 238 style names. Roughly: format the realm's name as a domainname, then 239 format the DANE TLSA resource record set's (RRset) domainname per- 240 DANE, using the KDC's port number. Note that the KDCs will usually 241 not speak TLS, though there is an extension for using TLS in the KDC 242 over TCP protocol. For example, the TLSA RRset for any KDC for the 243 DESTINATION.EXAMPLE realm might be named 244 _88._tcp.destination.example.] 246 5. Application Programming Interface Considerations 248 For non-LoF/TOFU uses the main security consideration for 249 applications is that improved scalability for Kerberos realm 250 traversal implies larger Kerberos universes, and the larger a 251 universe of trust the more important it is to have useful and 252 expressive local policy for evaluating the trustworthiness of any 253 given transit path. Because in most applications local policy should 254 be a component external to the application, there is little impact on 255 APIs here. However, an implementation may wish to provide 256 applications with interfaces for specifying policies, either named or 257 by value. 259 5.1. API Considerations for LoF/TOFU Authentication 261 For LoF/TOFU uses there is a critical requirement that APIs not 262 permit accidental aliasing of principal names as a result of LoF/TOFU 263 being used. The simplest way to do this is to use a fingerprint of 264 the peer principal's public key as their principal, and/or a 265 fingerprint of the peer principal's realm's public key as their 266 realm. 268 [[anchor1: For interoperability and compatibility we ought to specify 269 what fingerprint algorithm to use, perhaps one of the SSHv2 270 fingerprint algorithms, such as in RFC4255, but those use weaker 271 hashes...]] 273 5.2. GSS-API Naming Considerations 275 There are no GSS-API-specific considerations. The naming 276 considerations described in Section 5.1 and the naming attributes 277 defined in [I-D.williams-kitten-generic-naming-attributes] are 278 sufficient. Note however that information about how PKCROSS was used 279 to establish symmetrically-keyed cross-realm principals is lost and 280 will not appear in the transit path in tickets issued by KDCs reached 281 via such cross-realm principals. 283 [[anchor2: Actually, we may need to specify some interfaces by which 284 to indicate that the user wishes to alias a pseudonymous name. 285 Perhaps we can do so by applying GSS_Set_name_attribute() to a peer 286 MN obtained from GSS_Inquire_context()?]] 288 6. Security Considerations 290 [[anchor3: All the security considerations of Kerberos and PKI apply. 291 Security considerations are discussed throughout this document.]] 293 Scaling up the universe of realms reachable via any trust path 294 necessarily dilutes trust overall, but not for specific paths. On 295 the other hand, by shortening transit path lengths trust can be 296 improved, though some short transit paths will have been 297 symmetrically keyed using this PKCROSS protocol and therefore will be 298 longer than they appear to be. These are subjective notions of 299 trust, of course. 301 6.1. Loss of Cross-Realm Principal Trust Establishment Information 303 Note that once a cross-realm principal is symmetrically keyed no 304 information about how that keying operation took place will appear in 305 tickets issued by that TGS principal. 307 Note also that the Kebreros transit path encodes only realm names 308 (including X.500-style names, thus PKIX certificate subject and 309 issuer names), and lacks any public key information that might be 310 useful for pinning. However, the certificate validation path for 311 each realm in a transit path SHOULD be included in the transit path. 313 6.2. Security Considerations for LoF/TOFU 315 LoF/TOFU has additional security considerations. To start there is 316 the obvious susceptibility to peer impersonation / man-in-the-middle 317 (MITM) attacks on initial contact, which is mitigated by the 318 attacker's need to always remain in the middle in order to avoid 319 detection. 321 LoF/TOFU require the ability to remember peers' pseudonymous 322 identities -- their public keys (or certificates), otherwise one 323 remains vulnerable to peer impersonation / MITM attacks at all times. 324 This requires synchronization of peer pseudonym databases across 325 multiple devices (where users have multiple devices), which may not 326 always be possible or performed. 328 It is critical that existing applications not be broken by the 329 ability to use LoF/TOFU in new Kerberos implementations when those 330 applications are re-linked with newer Kerberos implementations. To 331 ensure this we require the use of public key fingerprints as 332 principal and/or realm names; local mappings of learned pseudonym 333 mappings onto semantically meaningful names are permitted where the 334 user can validate the mapping. But keep in mind that most users 335 never actually do much to verify peers' public keys in any 336 application/protocol that provides LoF/TOFU [references for this 337 would be nice -Nico]. 339 See Section 3.3.1 for additional requirements for LoF/TOFU 340 authentication. 342 6.3. On the Need for a Common Transit Path Policy Language 344 There are no standard ways to express authorization policies for 345 trust transit paths for either Kerberos nor PKI. A standard language 346 for this would be extremely useful. Such a language should allow for 347 the expression of policies for both, clients and services. Such a 348 language should allow for the expression of complex realm/domain/ 349 other naming, and should allow for HSTS-style pinning [add references 350 -Nico]. Such a language should allow for multiple paths where 351 desired, and should allow for more than path rejection: it should 352 also allow for reducing the entitlements assigned to a peer/realm for 353 authorization purposes. 355 The need for a standard transit path policy expression language is 356 not new, and such a language is broadly and generally needed. 357 Therefore such a language is outside this document's scope. 359 7. IANA Considerations 361 [[anchor4: Allocate the new KDCOptions flag (USE-SESSION-KEY-AS- 362 REALM-KEY) and authorization-data element (AD-CLIENT-CERTIFICATE).]] 364 8. References 366 8.1. Normative References 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, March 1997. 371 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 372 Request Syntax Specification Version 1.7", RFC 2986, 373 November 2000. 375 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 376 Kerberos Network Authentication Service (V5)", RFC 4120, 377 July 2005. 379 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 380 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 382 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 383 Housley, R., and W. Polk, "Internet X.509 Public Key 384 Infrastructure Certificate and Certificate Revocation List 385 (CRL) Profile", RFC 5280, May 2008. 387 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 388 of Named Entities (DANE) Transport Layer Security (TLS) 389 Protocol: TLSA", RFC 6698, August 2012. 391 [RFC6717] Hotz, H. and R. Allbery, "kx509 Kerberized Certificate 392 Issuance Protocol in Use in 2012", RFC 6717, August 2012. 394 [I-D.williams-kitten-generic-naming-attributes] 395 Williams, N., "Generic Naming Attributes for the Generic 396 Security Services Application Programming Interface (GSS- 397 API)", draft-williams-kitten-generic-naming-attributes-00 398 (work in progress), July 2013. 400 8.2. Informative References 402 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 403 Protocol Architecture", RFC 4251, January 2006. 405 Author's Address 407 Nicolas Williams 408 Cryptonector, LLC 410 Email: nico@cryptonector.com