idnits 2.17.1 draft-vanrein-internetwide-realm-crossover-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 215: '...ity, length considerations MUST NOT be...' RFC 2119 keyword, line 218: '...he utf8-username MUST be supported wit...' RFC 2119 keyword, line 219: '...ts DNS wire form MUST support sizes up...' RFC 2119 keyword, line 225: '...e of an identity MUST therefore be sup...' RFC 2119 keyword, line 230: '...YOID portability MUST be supported up ...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 28, 2020) is 1298 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) == Unused Reference: 'RFC5321' is defined on line 834, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6238 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Van Rein 3 Internet-Draft InternetWide.org 4 Intended status: Standards Track September 28, 2020 5 Expires: April 1, 2021 7 InternetWide Identities with Realm Crossover 8 draft-vanrein-internetwide-realm-crossover-00 10 Abstract 12 Domains and domain user identities are available in many protocols, 13 and can be expressed as part of the URI grammar. This document 14 outlines how clients can bring their self-controlled identities over 15 when crossing over to foreign realms that rely on authenticated user 16 identities. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 1, 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Bring Your Own IDentity as a Usage Pattern . . . . . . . . . 3 54 3. Grammar of Identities . . . . . . . . . . . . . . . . . . . . 4 55 4. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Example of a Local Identity Grammar . . . . . . . . . . . 5 57 4.2. Example Targets for Access Control . . . . . . . . . . . 6 58 4.3. Example Regimen for Access Control . . . . . . . . . . . 7 59 5. Realm Crossover Techniques . . . . . . . . . . . . . . . . . 9 60 5.1. Realm Crossover for Kerberos . . . . . . . . . . . . . . 9 61 5.2. Realm Crossover for SASL . . . . . . . . . . . . . . . . 10 62 5.3. Realm Crossover for PKIX . . . . . . . . . . . . . . . . 12 63 6. New Application Protocols . . . . . . . . . . . . . . . . . . 13 64 6.1. Remote PKCS #11 . . . . . . . . . . . . . . . . . . . . . 13 65 6.2. Keyful Identity Protocol . . . . . . . . . . . . . . . . 13 66 6.3. Helm Access (from Arbitrary Nodes) . . . . . . . . . . . 14 67 6.4. InternetWide Roaming . . . . . . . . . . . . . . . . . . 16 68 7. Normative References . . . . . . . . . . . . . . . . . . . . 17 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 71 1. Introduction 73 Many protocols identify clients and servers through a domain name or 74 a user at a domain name. Domain names follow the stepwise delegation 75 of authority that is engrained in DNS, and an added username is 76 generally considered a further refinement that falls under the 77 authority of the named domain. 79 URI grammar mirrors this idea in its authority section. Some 80 additional information is present to facilitate resource location 81 beyond an identity; these involve the scheme and an optional port, 82 and for some schemes there may be a host name as a mild 83 overspecification for a domain. 85 InternetWide Identity, as introduced herein, allows domain.name and 86 user@domain.name identity forms across protocols, and when included 87 in a URI it treats any path, query part, port, URI scheme and host- 88 instead-of-a-domain as information beyond the abstraction level of 89 interest to identity. In other words, variable paths, host names, 90 ports and service protocols can occur in URIs that represent the same 91 identity. 93 InternetWide Identities are domain-scoped and intended for use in 94 foreign servers that may reside in the client's domain or any other 95 domain. We informally refer to this idea as "Bring Your Own IDentity 96 (BYOID)" and to the technology facilitating it as "Realm Crossover" 97 for domain.name and user@domain.name identities. 99 Within a protocol, the client and service may each have their own 100 identity and when represented as a URI they may differ in many ways, 101 specifically including a possibly different domain name. This is 102 common for communication protocols such as SMTP or XMPP. It is less 103 common for protocols granting access to resources, like HTTP, where 104 resources may be specified with a URI but client identity is an 105 after-thought that gets mixed into that one URI as though it were a 106 service-side identity. This conflation of client and service domain 107 relaxes when the client identity is described with its own URI, 108 allowing better integration with the client realm and other services 109 working for it. 111 Foreign services generally implement some form of access control, 112 founded on an authenticated client identity. The process of 113 authentication validates the client domain name through such 114 mechanisms as DNSSEC with DANE and TLS. An identity callback to the 115 client realm can then add the user part of the client identity, 116 according to a source whose prerogative it is to define it. The 117 foreign service composes the domain.name that it validated for the 118 client with this user part to find a user@domain.name. 120 Since the client's username is provided under a domain's authority 121 over user names, it is possible to modify that part before it is 122 supplied to the foreign service. The name of the foreign service can 123 be a parameter in making this choice, especially when it is 124 authenticated. This point of change to the user name can be helpful 125 to change to an alias for client privacy; it may be used to slip into 126 a group or role; and it can support clients from yet another realm to 127 be represented by an alias or group or role under the client domain. 129 This document only outlines the ideas and protocol modifications that 130 can realise them. Specifics for each of the implements are deferred 131 to separate documents, even when the concepts described herein have 132 already been shown to work in code. 134 2. Bring Your Own IDentity as a Usage Pattern 136 The general usage pattern introduced with InternetWide Identity is 137 one where a client controls a set of usernames, residing under a 138 realm of its own choosing. This client realm is implemented under a 139 client domain name. The client may approach services running under 140 the same or any foreign domain. In either case, the client brings 141 their own identity composed of the client username and client domain; 142 the client realm actively facilitates authentication under this 143 composite identity. 145 As part of client control over their own identity, a service-specific 146 client username may be selected from among a set of pseudonyms 147 available to the cient. This enables the client to manage their 148 identity, and the client realm can provide a number of forms to 149 facilitate this; clients may create fresh identities or offer 150 "+alias" extensions, or switch to any of a group member or role 151 occupant, or even to a shared identity for an entire group or role. 152 The client realm or their user agent may remember choices made in the 153 past and suggest them again during new encounters with the same 154 service. 156 The design challenge of InternetWide Identity is to facilitate these 157 patterns in current-day protocols. This calls for additional Realm 158 Crossover protocols and techniques, and the sections below outline 159 how application protocols with Kerberos [Section 5.1] and/or SASL 160 [Section 5.2] authentication can be extended to connect client and 161 service realms, usually without modifications to application-layer 162 protocols. It also explains how a distributed Public Key 163 Infrastructure can be relied upon with similar techniques. 165 The general pattern of Realm Crossover is founded on the two-level 166 authority of a user@domain.name identity. Though host, port and 167 protocol as well as path and query string may be useful to locate a 168 resource and for that reason incoporated into a URI, the proposed 169 InternetWide Identity abstracts from those elements to allow shared 170 identities across a variation of services and protocols. Only the 171 domain and the username are considered for identity. The foreign 172 service starts by authenticating the domain and makes an identity 173 provider callback secured with mechanisms like DNSSEC, DANE and TLS. 174 The callback should be validated to a point where its authority over 175 usernames under the domain is certain. The callback can then be 176 used, in a manner specific to the Realm Crossover technology, to 177 authenticate the username underneath its domain. The composition of 178 these two elements, username and domain, with an "@" to separate the 179 fields, forms the full identity as it is further considered by the 180 foreign service. This approach can be used for client identities, 181 but may even be useful to validate service identites. 183 3. Grammar of Identities 185 The grammar of client and service identities are related to the 186 definition of a NAI with UTF-8 support [RFC7542]. However, the NAI 187 defaults to realm-internal use but BYOID always needs to express the 188 domain, so the root of the grammar tree is different: 190 identity = utf8-username "@" utf8-realm 191 identity =/ utf8-realm 193 The grammars of utf8-username and utf8-realm follow the NAI 194 specification [Section 2.2 of [RFC7542]] and neither may include the 195 "@" character. The incorporated UTF-8 grammar [RFC3629] only allows 196 the shortest representation for each code point. 198 The utf8-username and utf8-realm are both considered to be case- 199 insensitive, so technologies relying on Realm Crossover techniques 200 can infer identity equality when nothing differs but for letter case. 202 The utf8-realm is a domain name under which users may be defined; 203 note how this domain is not represented in the Internationalised 204 Domain Name form (IDNA) [RFC5890] that is used on the wire in DNS, 205 but as an utf8-realm that can be mapped from or to IDNA for DNS- 206 related purposes. This allows rendering of domain names to users in 207 the international form that they expect. 209 Host names, if they occur in a URI or as part of a protocol, must be 210 translated to a domain name in a manner that may be specific to the 211 protocol, but a reasonable general strategy might be to allow 212 precisely one level to be stripped off when no definitions in DNS 213 suggest otherwise. 215 For consistent BYOID portability, length considerations MUST NOT be 216 constrained by support infrastructure beyond a general minimum, which 217 follows the email limits [Section 4.5.3.1 of [RFC5321]] and IDNA. 218 The utf8-username MUST be supported with sizes up to 64 octets and 219 the domain in its DNS wire form MUST support sizes up to 255 octets. 220 Note that the DNS wire form can be more compressed than the 221 utf8-realm [Section 4.2 of [RFC5890]] because UTF-8 can use up to 4 222 octets for a Unicode code point, while IDNA can get up to a full 223 Unicode code point per DNS octet once it is initialised; a safe 224 minimum size to be certain to hold any utf8-realm is 1020 octets. 225 The size of an identity MUST therefore be supported with sizes up to 226 1085 octets. Note that this imposes constraints on usable RADIUS 227 implementations and the RADIUS User-Name attribute cannot be used to 228 contain the utf8-realm value; the User-Name in a RADIUS 229 implementation may even be unsuitable to carry the utf8-username, 230 which for BYOID portability MUST be supported up to 64 octet sizes, 231 whereas RADIUS permits a maximum size of 63 octets in the User-Name 232 field. 234 4. Example Use Cases 236 This section informally describes use cases that may be useful. 238 4.1. Example of a Local Identity Grammar 240 Under the prerogative of a realm's identity provider a more specific 241 grammar may be used, and some forms may even be distinguished by 242 notation. Such distinctions however, MUST NOT be assumed by foreign 243 services and SHOULD NOT be assumed by anything in the provider's 244 realm if that would break BYOID portability. Having said that, we do 245 give a few informative ideas: 247 o john@example.com might be a user 249 o john+cook@example.com might be a light-weight alias, 250 administratively scoped under user john@example.com 252 o mary@example.com might be a different user, or an external user 253 granted a local alter ego, or an unrecognisable pseudonym for 254 john@example.com 256 o cooks@example.com might be a group of users that can be addressed 257 all at once by a variety of services, each with their own group 258 semantics 260 o cooks+john@example.com might be a group member for 261 cooks@example.com, as an in-group pseudonym for a user under the 262 same or another domain 264 o +stove@example.com might represent a service 266 o +stove+nr3+elt5@example.com might represent a service with sub- 267 addressing parameters nr3 and elt5 269 4.2. Example Targets for Access Control 271 The targets of access control are often called "resource". We 272 specify a few forms that may be useful to consider, without it 273 meaning to be the last word. 275 One form worth considering might be a Communication ACL. For a given 276 local identity, this ACL would list the remote (client) identities 277 that are welcomed for communication. A concrete usage pattern of 278 this mechanism could be to blacklist everything but a few welcomed 279 peers; or to whitelist everything but for invasive parties; or to 280 graylist access and require the prospective communication partner to 281 jump through some hoops before being welcomed. It is RECOMMENDED to 282 verify access from a remote identity before initiating communication 283 with them, thus ensuring their ability to respond to the sending 284 identity. 286 The form of a Communication ACL is very general, and covers any 287 protocol that connects a remote identity with the local identity in 288 control of the ACL. So, after sending an email over SMTP, a response 289 over SIP is also possible and LDAP may grant download for public keys 290 for the local identity based on the same Communication ACL for the 291 local identity. But while the Communication ACL spans across 292 protocols, it should not span identities; a local user is likely to 293 use pseudonyms for the specific purpose of regulating access to this 294 identity. Crossover should at best be limited to redirection from an 295 access-blocking identity to a welcoming one. 297 Another general form could be that of a Resource ACL, which may be 298 centered around an identity in the form of a UUID [RFC4122]. Again, 299 this need not be constrained to a protocol but may represent more 300 general ideas, such as "storage space" or "versioning system". 301 Whether these are delivered over HTTP, LDAP, MQTT or GIT should not 302 matter to the access control mechanism. Related, but different, are 303 Resource Instances, which expand a general idea with a UUID-specific 304 string format to describe a particular instantiation of the general 305 idea; for example, a collection or object in a storage space; for 306 example, a repository or version in a versioning system. 308 4.3. Example Regimen for Access Control 310 Access control is exercised while a service is accessed. The process 311 starts with an authenticated client identity and derives what access 312 rights may be granted to the identified client. 314 The facilitation of BYOID in access control demands that the realm in 315 the client identity is fully taken into account. When any local 316 realm is at best used for compressed representation but not to 317 differentiate rights, an access control solution can be completely 318 open to foreign clients. 320 One difference between foreign clients and local ones is the level of 321 trust bestowed on them, another is the level of knowledge about their 322 identity grammar. Specifically, the username forms suggested above 323 for "+service" or perhaps "+service+arg1+arg2+arg3", for 324 "client+alias" or "groupname+membername" may all have local meaning, 325 especially because for a given name part "service" or "client" or 326 "groupname" there is some local knowledge about the kind of identity 327 that they represent. Though being permissive to foreign clients is 328 vital for BYOID, differentiating rights for local identities (and 329 identity patterns) can be useful in many operational contexts. 331 As a general mechanism for access control, it is RECOMMENDED to 332 iterate over a client identity by gradually generalising the form. 333 Each of the forms might be called a "selector". Going from concrete 334 to abstract, ach Selector could serve as a (partial) identity string 335 while looking for matching access rules. Such lookups could also 336 incorporate the target of access control. Flags representing 337 specific access rights such as read and write could be part of the 338 lookup or returned as a result of it. The first identity for which 339 an access rule matches is considered the proper one for the client 340 identity being iterated over. 342 The most specific username is the utf8-username field that passed 343 authentication. The most abstract username is a wildcard, which we 344 shall write as "". For local users, it may make sense to iterate 345 over more specific forms as well, such as splitting after internal 346 "+" signs. For example, "john+cook" could yield a list "john+cook", 347 "john+" and "" going from specific to general. 349 The most specific domain name is the utf8-realm field that passed 350 authentication. The most abstract domain is the top-level domain 351 ".", and intermediate domains can be written with a prefixed dot to 352 distinguish them from a full domain name. For example, "example.com" 353 could yield a list "example.com", ".com" and "." going from specific 354 to general. 356 The combined iteration for a client identity uses domain iteration as 357 an outer loop and username iteration as an inner loop. So, combining 358 the examples above including local interpretation of the username 359 part, "john+cook@example.com" could yield a list 360 "john+cook@example.com", "john+@example.com", "@example.com", 361 "john+cook@.com", "john+@.com", "@.com", "john+cook@.", "john+@.", 362 "@." where the latter is always the most abstract form found for a 363 client@domain.name form. 365 Most of this example list is likely to remain unused; several of 366 these forms could be blocked with pragmatic rules, such as barring 367 ".com" domains from an ACL. When also the local interpretation of 368 the username is barred, the lookups for such a remote client are 369 reduced to "john+cook@example.com", "@example.com", "john+cook@." and 370 "@." forms only, but for "john+cook@labs.example.com" there would 371 still be the meaningful forms "john+cook@labs.example.com", 372 "@labs.example.com", "john+cook@.example.com", "@.example.com", 373 "john+cook@." and "@." to consider in the ACL. 375 Note the importance of the initial dot in the domain name iteration. 376 It differentiates identities as defined by a realm from identities as 377 defined by a child realm. One other choice that an ACL might make is 378 to constain the iteration to go up one domain level and allow "." as 379 a wildcard domain. 381 In general, the application calling for access control is in the best 382 position to determine what to consider. An SMTP port 25 for external 383 submissions may not want to consider internal identity forms, whereas 384 an SMTP port 587 for submission by internal users may desire just 385 that. 387 5. Realm Crossover Techniques 389 This section details how Realm Crossover may be established with 390 Kerberos and SASL, and how PKIX may benefit from it. The 391 descriptions are provided to sketch the structure of the solution, 392 but complete details are worked out in other documents. 394 5.1. Realm Crossover for Kerberos 396 Kerberos uses a realm controller known as the KDC. It is possible 397 for the KDCs of two realms to connect, though this is not a dynamic 398 process that can be called upon when a client first attempts to acces 399 a foreign service. Realm Crossover for Kerberos is an "Impromptu" 400 extension to the existing facilities for Realm Crossover. 402 Only the client KDC and service KDC need to support Realm Crossover 403 to allow this to work. Most current-day clients facilitate principal 404 name canonicalization [RFC6806], which suffices for Realm Crossover. 405 The client KDC needs to realise that a request was made for a service 406 that is part of an external realm, obtain a (new or pre-existing) 407 realm-crossing relation with that realm's KDC, and respond with a 408 server referral [Section 8 of [RFC6806]] in order to redirect the 409 client, armed with realm-crossing credentials, to the KDC of the 410 service realm. 412 For the creation of a new, impromptu realm crossover relation between 413 two KDCs, a new protocol KXOVER has been devised. It builds on TLS 414 and derives a crossover key from the TLS master key. As part of the 415 KXOVER protocol, details such as a time window for crossover are 416 negotiated. Since the same crossover key can help any client on one 417 KDC to connect to any service on another KDC, this procedure is 418 efficient. Only the first "impromptu" call upon the remote KDC can 419 be somewhat time-consuming; beyond that, the procedures fall back to 420 symmetric key management only. When a crossover ticket is used 421 regularly, it would make sense to refresh it before the old ticket 422 expires. 424 It is worth noting that the secrecy of the crossover keys established 425 over TLS are only as secure as TLS is. When no Post Quantum 426 mechanisms are used, the crossover key derived by the client and 427 service realm could be grounds for future abuse. The security model 428 of Kerberos permits derivation of all derived keys and that includes 429 encryption keys. Although Kerberos with proper initiation can be a 430 Post Quantum technology, this may no longer hold under Realm 431 Crossover. 433 Kerberos supports anonymity, but that would not allow distinction 434 between different clients. It does not facilitate pseudonyms when 435 requesting a particular service on another realm; the KDC however, is 436 in a perfect position to do just that. Extensions can be easily 437 imagined, whereby a client sets a flag in the initial exchange to 438 indicate support for client identity changes, either from the KDC's 439 recollection of previous desires or from an explicit request by the 440 client. As long as the KDC reflects this flag, identity changes 441 could be requested or allowed as a protocol extension. 443 The current DNS records for Kerberos specify where to find the KDC 444 for a realm, but not for a service. This was initially considered 445 insecure, but since then DNSSEC has been rolled out, and it can now 446 be done securely. This means that a client or its KDC can look for a 447 service host or domain, infer the realm under which it resides, and 448 lookup the ticket for the protocol and host/domain under that realm. 449 This is not current practice yet. 451 In summary, the extensions to support Kerberos Realm Crossover are 452 (1) the KXOVER protocol, (2) DNS lookup of realm names for hosts/ 453 domains, (3) optional support of pseudonymity. With the exception of 454 the optional last point, these can be implemented in the KDC alone. 456 5.2. Realm Crossover for SASL 458 SASL authentication is built into many Internet protocols. It 459 facilitates an extensible set of mechanisms, passed inside the 460 application protocol which remains blissfully unaware of its details 461 and upgrades. 463 It is not generally safe to carry SASL over plaintext connections, 464 and the customary use case runs it within a secure application 465 protocol, such as after a STARTTLS exchange. To avoid undetected 466 relaying of SASL traffic to another resource, a precaution of channel 467 binding may be used, where non-secret but unmistaken parts of the 468 secure application protocol are mixed into a cryptographic 469 computation to assure that the SASL server is the assumed one. 471 To support Realm Crossover, it is possible to pass SASL to a backend 472 server over Diameter [RFC6733]. The backend would be selected for 473 the client's realm and looked up with Diameter's NAPTR and) SRV 474 records in DNSSEC and connected under protection of DANE and (D)TLS. 475 This is effectively an identity callback to a client realm. Under 476 Diameter, authentication is bidirectional, so the client realm is 477 aware of the requesting service realm. 479 Diameter is valuable because it is designed to authenticate across 480 administrative domains, and pass success or failure along with 481 descriptive attributes such as an authorisation username to a 482 requesting service realm. This usage is called Network Access 483 Service [RFC7155]. The value of passing just success or failure by 484 default is that no resources are made available; as a result, a 485 Diameter service can be made available as a public authentication 486 callback service, unlike a resource-supplying protocol such as IMAP. 488 Care must be taken to not ever pass traffic back up from Diameter to 489 a higher-level protocol. SXOVER ensures this by loosing vital 490 information in that case, namely for channel binding. Services other 491 than Diameter MUST reject externally supplied channel binding octet 492 strings and instead form their own. That way, a resource-supplying 493 application protocol could not possible be attacked in the backend of 494 a foreign service contacted by the client. That is, not when channel 495 binding is being used. The flip-side of this coin is that the 496 foreign service contacted by the client MUST relay channel binding 497 information to its Diameter backend, which then forwards it to the 498 point where cryptographic computations are performed, in the client 499 realm. Channel binding effectively becomes the client's 500 authentication of the foreign service. 502 Based on this, only SASL mechanisms that support channel binding are 503 suited for Realm Crossover. There is another requirement however, 504 and that is end-to-end encryption. Given that SASL mechanisms are 505 not generally safe to pass over unencrypted channels, they cannot 506 generally be trusted to pass through a foreign service either. A 507 secret between the client and its realm must be obtained beforehand, 508 and used to encrypt the exchange. Note the relative ease of 509 obtaining such a key relative to proving client identity. A special 510 SASL mechanism can then employ this secret, along with channel 511 binding information, to securely wrap another SASL mechanism that 512 does not need to live up to these requirements. That special SASL 513 mechanism is GS2-SXOVER-PLUS; it is possible that other mechanisms 514 are devised to allow the same usage pattern however. 516 Two last concerns to note for the special SASL mechanism are that it 517 must mention the client's realm in a form readable to the foreign 518 server. This part will also be validated by the foreign server, 519 while making the Diameter back-call. The wrapped SASL mechanism 520 therefore does not supply the client realm, but only its username, 521 precisely its prerogative to define. Also, the form of channel 522 binding used must be visible to the foreign server, so it can pack 523 the information for relaying over Diameter. This is generally 524 possible with GS2 mechanisms, though other forms can have specialised 525 representations for the same information. 527 Note that not all these concerns necessarily apply for clients that 528 are local to the "foreign" service. Even when they may also pass 529 over Diameter, their traffic may remain "internal" and "trusted" and 530 therefore more mechanisms may be available than for a truly foreign 531 client. It is common in SASL to allow the server to present 532 acceptable SASL mechanisms, so this can be part of operational 533 practices. 535 To allow SASL over Diameter, a few attribute-value pairs need to be 536 defined under its Network Access Profile [RFC7155]. These are (1) 537 SASL-Token, for relaying SASL's binary octets of a token in either 538 direction, but only when one is supplied by the SASL endpoint; (2) 539 SASL-Mechanism, a string listing space-separated mechanism names that 540 are acceptable to the foreign service, or selected by the client; (3) 541 SASL-Channel-Binding, to relay binary channel binding information 542 from the foreign service to the client's Diameter server, and to 543 allow the client and its realm to work out that no extra resources 544 are in the loop. 546 Not all application protocols support SASL. Modern IRC does, and may 547 benefit from incorporating Realm Crossover to make abusive patterns 548 less likely, and to reserve usernames for returning clients. The 549 most notable omission is HTTP, which resorts to higher layers, often 550 involving manual actions and code mixtures with executable content 551 from uncontrolled remote sites. An extension of HTTP with SASL is 552 part of our proposal for realm crossover as an overall solution. 554 In summary, the extensions to support SASL Realm Crossover are (1) 555 support for SASL over Diameter, (2) the GS2-SXOVER-PLUS mechanism and 556 its incorporation into user agents and SASL over Diameter; (3) the 557 reliance on Diameter for client authentication in foreign servers. 558 Finally, (4) non-SASL-aware protocols need to be extended to support 559 SASL. 561 5.3. Realm Crossover for PKIX 563 The definition of PKIX references LDAP for the retrieval of 564 certificates from a certificate's DistinguishedName. Given the 565 potential for access control when Realm Crossover enables requesters 566 to authenticate, arbitrary privacy controls can be enforced using 567 these mechanisms. LDAP services can pass through STARTTLS and the 568 certificate used may be assured through DNSSEC and DANE to allow 569 remotes to validate the authority of the information in LDAP, 570 specifically when its DistinguishedName patterns coincide with the 571 domain name [RFC2247] and when usernames are located with (uid=...) 572 search filters. 574 When identities are managed with the BYOID intent, it makes sense to 575 create key pairs for PKIX, OpenPGP and perhaps OpenSSH and store 576 those in LDAP for retrieval by approved parties. This establishes 577 the long-missed Public Key Infrastructure for the Internet, to 578 benefit security of email and most other forms of communication. 580 Note how PKIX currently relies on "central" organisations to approve 581 of certifictes, and how LDAP may be supportive of a more distributed 582 mechanism. Also note how the mechanisms can be combined for maximum 583 strength; one example use of this would be to facilitate federations 584 with authentication that spans the Internet plus a root key that 585 facilitates just the federation. 587 6. New Application Protocols 589 The idea of BYOID and its technological embedding as Realm Crossover 590 allow a few useful ideas to be worked out in new application 591 protocols. The general idea of these protocols is described below, 592 but the complete details are described in other documents. 594 6.1. Remote PKCS #11 596 Clients may want to use key-based mechanisms even on platforms that 597 cannot be trusted to protect these well, such as a mobile phone or 598 other easily lost device. Such applications, as well as the desire 599 to use the same keying material on multiple devices and the 600 reflection that operational control of private keys with proper 601 rollovers is difficult and may for a large portion of users better be 602 left to their administrators, all combine to the idea that a Remote 603 PKCS #11 service may be useful. 605 When identities are generated along with public key certificates that 606 can be looked up in LDAP, it is useful to facilitate the matching 607 private keys in such a Remote PKCS #11 service. 609 We have prepared an LDAP scheme to reflect private key references 610 alongside public key certificates (with intended readability only to 611 the key owners) and we have prepared a direct mapping of the PKCS #11 612 interface to a request/response format that supports locally callable 613 functions that are actually applied remotely to private keys 614 contained there, perhaps in a highly secured context. 616 6.2. Keyful Identity Protocol 618 The enhancement of authentication with Realm Crossover allows a great 619 diversity of new use cases; but encryption still relies on the 620 publication of public key certificates by recipients. When the 621 requirement to encrypt sensitive content exists however, there is an 622 immediate urge to have all recipient's public keys and not make an 623 exception by sending unencrypted content to one recipient that lacks 624 one. In short, there is a desire for sender-initiated encryption. 626 We devised a Keyful Identity Protocol (KIP) to fulfil this need. Its 627 essential function is to take in a symmetric key and wrap it in a 628 manner that can only be decrypted by an authenticated party. In 629 other words, it provides encryption to any client who can 630 authenticate. The actual content is not passed over KIP, but the 631 session keys are. 633 Encryption of session keys is done with a fixed key stored in the KIP 634 service, and cryptographically bound to an access control list. 635 Requests to authenticate require no authentication, and are ideally 636 performed on a KIP service running under each recipient's domain. To 637 request decryption, a recipient must authenticate, and their session 638 key can be provided when the cryptographically bound access control 639 list allows it. 641 KIP can also be used to sign a checksum, which is a notably different 642 service from authentication. This requires authentication by the 643 signing party and is best done at their realm's KIP service. To gain 644 trust, a recipient would contact the KIP service under a (validated) 645 signer's realm and see it approved. 647 KIP Documents are a nested sequence of data and wrapped session keys 648 and signatures. This involves signed references, so an object may be 649 stored outside of a KIP Document, and still be validated by it. By 650 defining a media type for KIP Documents, a data URI [RFC2397] can be 651 made that triggers a handler when accessed by user agents such as 652 HTTP and SMTP clients. 654 The wrapped session keys of KIP underly the GS2-SXOVER-PLUS mechanism 655 Section 5.2, without other dependency on the protocol; KIP service 656 can be used to help clients to the initial key that provides end-to- 657 end encryption between their user agent and the identity callback 658 server in the client realm. 660 In spite of its potential strength, KIP is operationally really 661 simple to deploy. It requires a secure storage mechanism for its 662 fixed long-term key, but the only administrative control needed is 663 the creation and destruction of virtual hosts; and a basic roll-out 664 only needs one. KIP can be a client to Realm Crossover for 665 straightforward authentication. 667 6.3. Helm Access (from Arbitrary Nodes) 669 Domains may seem to be the anchor point for online identity, but in 670 reality they often have fallbacks to a single email address, to which 671 unencrypted email is sent. Other online resources reproduce this 672 insecure habit. Email address may go awry, and with it, possibly the 673 control over a domain name. The general problem here is that no 674 problem exists for "identity bootstrapping". Realm crossover can be 675 used to remedy that. 677 Online resources usually have a starting point, where administrative 678 control may be exercised, including the removal of the resource and 679 creation of new ones. It may even include the addition of 680 subordinate identities, such as domain users or subdomains under a 681 domain name. We introduce the general idea of a "Helm of Control", 682 or helm for short, as the point of access to this facility. 684 We propose the use of Realm Crossover to gain access to one's helm. 685 This involves authentication with a (possibly external) credential 686 and not the ability to receive unencrypted email, so it is already 687 more constrained. In addition, it should be straightforward to 688 control in a more refined access how control can be held. At the 689 very least, it is desirable to allow access form multiple (external) 690 identities to have no single point of failure when it comes to access 691 recovery. 693 Use cases may involve depositing credentials with others who can 694 serve as fallbacks for access. This is especially useful by handing 695 them their own access control, possibly leading to their own Helm, 696 where they can only control those online resources that they are 697 supposed to control. In general, a many-to-many mapping from 698 identity to online resource at a given provider seems the most 699 useful. 701 One use of this access pattern include control over the removal of a 702 person's online presence, for instance by family after a loved one 703 passes away or after a company goes into bankruptcy. At least some 704 laws discard an individual's right to privacy upon death and may 705 therefore not be supportive of a family's desire to erase online 706 presence without going through disturbing practices in full control 707 of a service provider; and not all of them see a benefit in 708 destroying data. 710 HAAN is short for Helm Arbitrary Access Node; the HAAN service 711 generates a worthless username and password from scratch. Note that 712 any fresh account is without value until it is setup with online 713 resources, perhaps by accessing a Helm. Though supplied by a given 714 realm, the HAAN service for a realm does not even need to store the 715 credentials; it generates a random username with a lot of entropy and 716 uses an internally held, fixed key to derive an accompanying 717 password. Later, when a client wants to gain access, the provided 718 username is combined with the fixed key to recompute the password and 719 perform any desired check. 721 The implementation of HAAN is founded on a SASL mechanism named GS2- 722 HAAN-GENERATE, which should be run directly with the supporting realm 723 (or perhaps through an end-to-end encryption tunnel like the one for 724 SXOVER). Later authentication is possible using any SASL mechanism 725 that uses a password, usually with GS2-SXOVER-PLUS wrapped around it 726 so a foreign provider can use it to gain access to its Helm. 728 It is not generally advised to require authentication when adding a 729 HAAN identity to a Helm. First, it exchanges more credential 730 information than strictly desired; second, users do not type 731 identities from slips of paper but use copy/paste; third, backups 732 exist in the form of additionally registered identities to access the 733 helm; fourth, because HAAN can generate extra entropy to allow 734 correction of typo's when a client enters a falsely entered identity 735 as an authorisation identity. When desiring a 128-bit security 736 level, HAAN might generate 160 bits and as long as going from the 737 proper 160-bit value to an authorisation identity can be described 738 with entropy less than the extra 32 bits, the validation with HAAN 739 can still provide the 128-bit security level. 741 Dedicated methods can be built for HAAN-generated secrets. One that 742 springs to mind is TOTP [RFC6238], where the only storage needed on 743 the server is for replay avoidance, and only when nothing specific to 744 the SASL exchange itself avoids replay. When replay is not to be 745 suspected, the TOTP exchange can be accepted immediately; otherwise, 746 a challenge/response exchange may remedy any risk of replay. The 747 server can safely err on the cautious side, and use something like a 748 Bloom filter to detect possibly replay over the past timer period. 750 In spite of its promising potential, HAAN is operationally really 751 simple to deploy. It requires a secure storage mechanism for its 752 fixed long-term key, but the only administrative control needed is 753 the creation and destruction of virtual hosts; and most roll-outs 754 will only support one. 756 6.4. InternetWide Roaming 758 Networking is increasingly becoming an application under management 759 of users. Network authentication is customarily generalised in EAP, 760 whereas application authentication is generalised with SASL. An 761 ability to run SASL over EAP supports the use of client credentials 762 for network access applications such as VPN, 802.1x or Bluetooth. 764 When SASL is backported over Diameter, an extra option arises, where 765 the user is offered a tunnel to a home network. Using ESP, such a 766 tunnel would be protected from content inspection and manipulation. 767 And quite interestingly, ESP could be carried over a multitude of 768 protocols. 770 When providing network access, this scheme has the benefit that 771 nothing is known about the traffic, and so no responsibility is taken 772 for those contents. Furthermore, the IP address from which this 773 content is shared is only a tunnel endpoint to a home realm, but not 774 a general carrier for traffic. This could be a type of service to 775 offer without concerns. 777 Packets of an ESP tunnel may travel over a variety of carriers, not 778 just over IP. There could be an embedding for directly carrying it 779 over ethernet or PPP, for example. There is an additional need for 780 key exchange, but the UDP encapsulation for ESP [RFC3948] solves that 781 with a simple prefix to the key exchange traffic, so that a complete 782 tunnel protocol arises. This tunnel protocol can pass through PNAT 783 using the UDP encapsulation. 785 This allows wired and wireless ethernets to employ 802.1x access 786 restriction with SASL over EAP, to open up an ESP/IKE uplink to a 787 tunnel server whose address information is provided in a Diameter 788 response when SASL over Diameter succeeds. A base station may 789 respond to a query for an "InternetWide Roaming" identity with just 790 this dialog. 792 Similar approaches might be employed with the Bluetooth Network 793 Encapsulation Profile to grant nearby nodes access to an ethernet, 794 albeit at much lower speed, but can reduce the ethernet header to 795 just the ethernet type. As a fallback scenario, mobile users may be 796 helped with the older L2TP/IPsec stack which is available by default 797 in most current-day configurations and this may serve as a fallback 798 in circumstances where InternetWide Roaming is not available in a 799 more direct form, but generic Internet access is. The simplified 800 access form however, can be particularly interesting for small 801 devices, especially when the ESP traffic is founded on a fixed key. 803 The integration of SASL into EAP adds a use case for key extraction 804 from SASL, which is sometimes considered an older possibility, but 805 which regains interest when it can setup end-to-end protection keys. 806 In a scenario where SASL is followed by ESP, it may provide extra 807 entropy to be mixed into the key exchange [RFC8784]. 809 7. Normative References 811 [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. 812 Sataluri, "Using Domains in LDAP/X.500 Distinguished 813 Names", RFC 2247, DOI 10.17487/RFC2247, January 1998, 814 . 816 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 817 DOI 10.17487/RFC2397, August 1998, 818 . 820 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 821 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 822 2003, . 824 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 825 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 826 RFC 3948, DOI 10.17487/RFC3948, January 2005, 827 . 829 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 830 Unique IDentifier (UUID) URN Namespace", RFC 4122, 831 DOI 10.17487/RFC4122, July 2005, 832 . 834 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 835 DOI 10.17487/RFC5321, October 2008, 836 . 838 [RFC5890] Klensin, J., "Internationalized Domain Names for 839 Applications (IDNA): Definitions and Document Framework", 840 RFC 5890, DOI 10.17487/RFC5890, August 2010, 841 . 843 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: 844 Time-Based One-Time Password Algorithm", RFC 6238, 845 DOI 10.17487/RFC6238, May 2011, 846 . 848 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 849 Ed., "Diameter Base Protocol", RFC 6733, 850 DOI 10.17487/RFC6733, October 2012, 851 . 853 [RFC6806] Hartman, S., Ed., Raeburn, K., and L. Zhu, "Kerberos 854 Principal Name Canonicalization and Cross-Realm 855 Referrals", RFC 6806, DOI 10.17487/RFC6806, November 2012, 856 . 858 [RFC7155] Zorn, G., Ed., "Diameter Network Access Server 859 Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, 860 . 862 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 863 DOI 10.17487/RFC7542, May 2015, 864 . 866 [RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, 867 "Mixing Preshared Keys in the Internet Key Exchange 868 Protocol Version 2 (IKEv2) for Post-quantum Security", 869 RFC 8784, DOI 10.17487/RFC8784, June 2020, 870 . 872 Author's Address 874 Rick van Rein 875 InternetWide.org 876 Haarlebrink 5 877 Enschede, Overijssel 7544 WP 878 The Netherlands 880 Email: rick@openfortress.nl