idnits 2.17.1 draft-vanrein-krb5-authzdata-diameter-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 : ---------------------------------------------------------------------------- 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 (October 20, 2018) is 2005 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 ARPA2.net 4 Intended status: Experimental October 20, 2018 5 Expires: April 23, 2019 7 Diameter Messages in Kerberos5 AuthorizationData 8 draft-vanrein-krb5-authzdata-diameter-00 10 Abstract 12 The Kerberos5 infrastructure is concerned with authentication, but it 13 can also carry AuthorizationData in a variety of formats. Diameter 14 is an extensible standard for the expression of authorisation 15 information. This specification defines an embedding of Diameter 16 data in the AuthorizationData fields of Kerberos5. 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 23, 2019. 35 Copyright Notice 37 Copyright (c) 2018 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. Embedding Diameter in Kerberos5 . . . . . . . . . . . . . . . 3 54 3. InternetWide Usage Pattern . . . . . . . . . . . . . . . . . 4 55 4. Example Application . . . . . . . . . . . . . . . . . . . . . 6 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 60 7.2. Informative References . . . . . . . . . . . . . . . . . 8 61 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 Kerberos5 [RFC4120] is a single-signon system that automatically 67 supplies users with authentication tickets to individual services. 68 Such tickets tend to last as long as a maximum user session, usually 69 up to a day. They are provided by a central realm service known as 70 the Key Distribution Center or KDC. 72 Though designed for authention rather than authorisation, KDC 73 exchanges lend themselves well to facilitate both. The message 74 formats can carry AuthorizationData consisting of a numerical tag and 75 data to be interpreted according to that tag. This specification 76 adds a tag value to describe AuthorizationData holding Diameter 77 protocol messages. 79 AuthorizationData can be included in requests to the KDC, and the KDC 80 can include AuthorizationData in a ticket. When requesting a service 81 ticket from the KDC, a single-signon ticket with possible 82 AuthorizationData is attached to that request. All this data is 83 protected in transit; requests to the KDC are encrypted with the TGT 84 secret or a sub-secret; tickets pass it to a service using a key 85 shared between the server and KDC. 87 Diameter frames [RFC6733] hold a list of Attribute-Value Pairs (AVP), 88 with optional nesting into group AVPs. The format is easily parsed 89 and applications exist (or can be defined) to capture a class of 90 usage scenarios. Among the existing applications is a network access 91 application that lends itself for most authorisation applications. 93 The purpose of using Diameter in this place is to employ the existing 94 communication infrastructure of Kerberos to pass authorisation 95 settings between hosts. The standardised format simplifies access to 96 services in foreign realms; this is useful to the InternetWide.org 97 purpose to Bring Your Own IDentity (BYOID), which requires passing 98 standardised authentication and authorisation information between 99 collaborating but otherwise independent parties. 101 2. Embedding Diameter in Kerberos5 103 Diameter messages consist of a header choosing an application, 104 followed by the AVPs that are meaningful within that application. 105 The header guides the interpretation of the AVPs and is therefore a 106 meaningful part in proper understanding of the exchange. This is why 107 inclusion of Diameter as Kerberos AuthorizationData must not be 108 limited to a set of AVPs but instead include a header. 110 Diameter messages are always carried over a protected transport such 111 as SCTP with DTLS or TCP with TLS, where the purpose is to mutually 112 authenticate Diameter Peers in protection of in-transit data against 113 rogue alterations and to conceal sensitive data from similarly 114 undesirable parties. These security requirements are alternatively 115 met when AuthorizationData is used to carry the Diameter frames. 117 Diameter makes a distinction between sessions and connections. 118 Connections represent coherent message carriers such as TCP or SCTP 119 connections, whereas a session is more conceptual relationship that 120 may span multiple connections and connections may carry multiple 121 sessions. Requests over one connection may even be responded to over 122 another. For the purposes of Diameter, passing messages through 123 Kerberos can be viewed as an alternative form of connection; the 124 collaboration between KDC and services can be considered a 125 connection, consisting of a multitude of individual packages but 126 together forming a coherent message carrier. 128 A normal exchange under Diameter is a request leading to a response. 129 This can be established by inclusion of a request in a message going 130 to a KDC, and a response coming out of it. We can also imagine 131 responses to be supplied as a pro-active hint, to prepare an answer 132 that might come up when interpreting a service request. This is 133 possible because the client KDC is asked for a service ticket, 134 allowing it to preview upcoming inquiries. The hint provided would 135 stand for the entire duration of the service ticket, effectively 136 turning such tickets into client-held caches of their authorisations. 138 Diameter connections must start interactions with a Capabilities 139 Exchange. This specification answers that with a default setup with 140 the Network Access Application [RFC7155] and possible overrides to 141 take place during administrative setup, such as during the creation 142 of service keys or the esstablishment of realm crossover. This 143 looseley addresses the requirement for Capabilities Exchange. 145 The looseness is warranted because the customary need for a 146 Capabilities Exchange is not fully applicable to the use of Diameter 147 messages in AuthorizationData, not even when crossing realms. First, 148 this can be used as a pro-active mechanism and it is generally safe 149 to ignore any misunderstood Diameter messages. Second, tickets tend 150 to be cached for a day, which makes their generation less resource- 151 demanding. Third, the purpose can help avoid traditional Diameter 152 traffic, thus limiting the danger of a lot of spurious network 153 traffic. 155 Peers that process Kerberos messages should not be considered 156 Diameter processing nodes, as they may be just passing traffic, 157 except for the end points that produce and consume Diameter messages 158 in AuthorizationData. Intermediate nodes may choose to process data 159 though; for instance, during realm crossover the KDC of the service 160 domain may remove authorisations that it does not find acceptable; 161 the service may assume that it's realm is managed thusly. In general 162 however, Kerberos defaults to passing AuthorizationData without 163 change, meaning that Kerberos nodes cannot be held accountable for 164 Diameter message content that it does not interpret. 166 3. InternetWide Usage Pattern 168 This section is not normative; it serves to present context. 170 The following patterns are proposed for the InternetWide.org project, 171 which aims to support secure and private interactions across realm 172 boundaries for standard Internet protocols, including but certainly 173 not limited to HTTP. 175 A general principle in the InternetWide Architecture is that users 176 can Bring Your Own IDentity (BYOID) which is implemented with names 177 with a local part and a domain part, basically like an email address 178 or Netword Access Identifier. When crossing over to a remote realm, 179 the intention is to allow a change to an alias that may be specific 180 to that remote realm, thus allowing better control of online 181 presence. 183 The InternetWide Architecture treats user services such as email and 184 web as what Diameter calls Network Access Servers; they grant access 185 to a facility, and need authorisation from the client's home realm. 186 Diameter was designed to allow this across realms, and the inclusion 187 of these forms in Kerberos tickets can greatly improve the 188 scalability of such interactions. 190 The Kerberos mechanism is very efficient for use across realms, as is 191 required under BYOID. Other current mechanisms tend to be less 192 efficient due to: 194 o Everything is connected through HTTP over TLS; 196 o The employed cryptography is public-key based; 198 o There is only limited opportunity for caching; 200 o Authorisation is performed on-demand; 202 o Authorisation signatures must be separately verified; 204 o The result is not protected against quantum computing. 206 In contrast, the proposed AuthorizationData used in Kerberos with 207 realm crossover permits: 209 o All protocols can be used, with authentication in only a few 210 exchanges; 212 o The employed cryptography is symmetric; 214 o AuthorizationData is cached for about a day with the client; realm 215 crossover is cached in the KDC; 217 o Authorisation is done pro-actively during authentication; 219 o AuthorizationData is protected along with the authentication of a 220 service ticket; 222 o Kerberos can withstand quantum computing. 224 At the start of a session, a user logs in to the KDC for his realm. 225 During the day, service tickets are requested. When the KDC needs 226 to, it will forward the user to a remote realm through realm-crossing 227 tickets, that the user follows using current Kerberos semantics 228 [RFC6806]. 230 For services in serviced realms, the KDC can insert dedicated 231 authorisation information into requested service tickets. 233 The KDC cannot be configured to grant the supply of information to 234 remote realms during the dissimination of realm-crossing tickets. 235 Such information should not be specialised for a service name found 236 in the request that caused it to release a realm-crossing ticket, 237 because clients tend to cache these tickets and thus be deprived of 238 this refinement for future use in the same realm. It is however 239 possible to supply more kinds of information, or generally usable 240 information, in such realm-crossing tickets. 242 The KDC of a service realm may prune information that does not apply, 243 or is considered improper, for a service for which it received a 244 request. This can be included into a specific ticket for a specific 245 service. Some authorisation information during realm crossover is 246 the prerogative of the client's KDC, other information is the 247 prerogative of the service's KDC. Identity is a good example of 248 client-sided control, whereas rights to write to a resource tend to 249 be decided about on the service side. The InternetWide Architecture 250 envisions standardised contracts between client and service realms 251 that may enhance the information that could pass. 253 A targeted service can retrieve authorisation information from a 254 service ticket, and be sure that it came from the KDC that 255 constructed this ticket. In case of a user from a realm that is not 256 local to the service's realm, the service may derive trust from any 257 filtering that it knows is being done in the KDC for the service 258 realm. 260 4. Example Application 262 This section is not normative; it serves as an example. 264 Shell services are often made available through OpenSSH [RFC4251] and 265 it is common to provide services (such as file transfer) as well as 266 tunneling (such as to a server port behind a firewall). Kerberos 267 access to these services take the form of rather general "host" 268 tickets that is also used for several other purposes on the same 269 host. 271 The multitude of access opportunities with one ticket calls for some 272 restriction, but a change of the ticket naming convention is not 273 practical. Additional content describing authorised purposes is. 274 Diameter messages can be useful to accommodate this. It may also 275 help to provide access to shared environments, where each client is 276 given a different kind of access profile. Even access to clients 277 without a local account may be possible under such conditions. 279 Everyday setups of OpenSSH are isolated; it may use a plugin module 280 to add Kerberos5 authentication and decide on the access and session 281 properties. These setups tend to work in isolation without 282 connectivity to a Diameter infrastructure, but having such data can 283 nonetheless be beneficial. 285 5. Security Considerations 287 This specification suggests some leniency in terms of attempting to 288 access Diameter services that may not be as formally negotiated. 289 This does mean that unrecognised messages should be silently ignored. 291 In typical uses of Diameter, this would rather cause an explicit 292 error message. As long as no actions are taken on unrecognised 293 content, this should not impact security, however. 295 Diameter messaging parties must take responsibility for what they 296 send. Kerberos peers pass AuthorisationData without looking, so 297 these peers cannot be held responsible and should be viewed as 298 communication channels, not Diameter peers. 300 During realm crossing, the right to setup certain authorisation 301 fields may vary. It is important for any trusting realm to be 302 mindful of this. Whether this concern is implemented in individual 303 services or generally dealt with in the realm's KDC is an operational 304 choice that can be made locally to the realm; the realm's KDC is 305 involved in realm crossover at the time that a service ticket is 306 requested by the foreign client. 308 During realm crossing, the client's KDC releases a general ticket for 309 a remote realm. The information contained in this ticket's 310 AuthorizationData may be visible to all services in the remote realm, 311 and so is subject to privacy concerns. It may be necessary to either 312 supply only generic information (such as descriptive attributes) or 313 use only one or a few foreign services per realm. 315 6. IANA Considerations 317 When IANA takes on the registration of AuthorizationData tags, it 318 will take the following allocation into account: 320 TODO 322 7. References 324 7.1. Normative References 326 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 327 Kerberos Network Authentication Service (V5)", RFC 4120, 328 DOI 10.17487/RFC4120, July 2005, 329 . 331 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 332 Ed., "Diameter Base Protocol", RFC 6733, 333 DOI 10.17487/RFC6733, October 2012, 334 . 336 [RFC6806] Hartman, S., Ed., Raeburn, K., and L. Zhu, "Kerberos 337 Principal Name Canonicalization and Cross-Realm 338 Referrals", RFC 6806, DOI 10.17487/RFC6806, November 2012, 339 . 341 [RFC7155] Zorn, G., Ed., "Diameter Network Access Server 342 Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, 343 . 345 7.2. Informative References 347 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 348 Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, 349 January 2006, . 351 Appendix A. Acknowledgements 353 This work was conducted as part of the InternetWide.org project, and 354 aims to support authorisation data that crosses over between 355 platforms and realms. Implementation projects under this 356 architecture are named ARPA2 projects. 358 Author's Address 360 Rick van Rein 361 ARPA2.net 362 Haarlebrink 5 363 Enschede, Overijssel 7544 WP 364 The Netherlands 366 Email: rick@openfortress.nl