idnits 2.17.1 draft-vanrein-krb5-authzdata-diameter-01.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 (February 28, 2019) is 1878 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 February 28, 2019 5 Expires: September 1, 2019 7 Diameter Messages in Kerberos5 AuthorizationData 8 draft-vanrein-krb5-authzdata-diameter-01 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 September 1, 2019. 35 Copyright Notice 37 Copyright (c) 2019 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. Use with Realm Crossover . . . . . . . . . . . . . . . . . . 5 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 57 6. Normative References . . . . . . . . . . . . . . . . . . . . 6 58 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 61 1. Introduction 63 Kerberos5 [RFC4120] is a single-signon system that provides the users 64 of its realms with authentication tickets to individual services. 65 Such tickets tend to be valid for the remaining user session, 66 typically up to a day. Service tickets are provided by a central 67 realm service known as the Key Distribution Center or KDC. 69 The KDC may not be able to supply tickets for all services. When it 70 knows that a service belongs to another realm, and when it can locate 71 a crossover key to the service's KDC, it will forward the user to a 72 remote realm through a realm-crossing ticket. The user follows such 73 tickets under current Kerberos semantics [RFC6806]. 75 Though designed for authentication and not authorisation, the realm- 76 centric position of a KDC makes it a suitable place to control both 77 aspects of access control. The message formats can indeed carry 78 AuthorizationData, consisting of a numerical tag and data to be 79 interpreted according to that tag. This specification adds a tag 80 value to describe AuthorizationData holding Diameter protocol 81 messages. 83 AuthorizationData can be included in requests to the KDC, and the KDC 84 can include AuthorizationData in a ticket. When requesting a service 85 ticket from the KDC, a single-signon ticket with possible 86 AuthorizationData is attached to that request by the Kerberos client. 87 All this data is protected in transit; requests to the KDC are 88 encrypted with the TGT secret or a sub-key; tickets carry it to a 89 service using a key shared between the server and KDC. The KDC can 90 prove to a ticket-receiving service that it originated certain parts 91 of AuthorizationData by wrapping it in CAMMAC [RFC7751] structures. 93 Diameter frames [RFC6733] hold a list of Attribute-Value Pairs (AVP), 94 with optional nesting into group AVPs. The format is easily parsed 95 and applications exist (or can be defined) to capture a class of 96 usage scenarios. Among the existing applications is an extensible 97 network access application that lends itself for authorisation 98 applications. These Diameter frames are herein proposed as an 99 AuthorizationData format in Kerberos. 101 The purpose of using Diameter in Kerberos is to employ the existing 102 authentication infrastructure of Kerberos to also pass authorisation 103 settings between hosts. The standardised format of Diameter 104 simplifies access to services in foreign realms; this is useful to 105 the InternetWide.org purpose to Bring Your Own IDentity (BYOID), 106 which requires passing standardised authentication and authorisation 107 information between collaborating but otherwise independent parties. 109 2. Embedding Diameter in Kerberos5 111 Diameter messages consist of a header choosing an application, 112 followed by the AVPs that are meaningful within that application. 113 The header guides the interpretation of the AVPs and is therefore a 114 meaningful part in proper understanding of the exchange. This is why 115 inclusion of Diameter as Kerberos AuthorizationData must not be 116 limited to a set of AVPs but instead include a header. Formally, we 117 define 119 AD-DIAMETER ::= -- A concatenation of byte strings: 120 -- 1. one Diameter Header, as defined 121 -- in Section 3 of RFC 6733 122 -- 2. zero or more AVP Headers, with 123 -- applicable AVP Data, as defined 124 -- in Section 4 of RFC 6733 125 -- The whole adhering to the Command 126 -- Code Format Specification defined 127 -- in Section 3.2 of RFC 6733 and its 128 -- extensions. 130 and shall use it under this specification when the preceding ad-type 131 field has value TBD assigned for this purpose. Note that AD-DIAMETER 132 does not follow an ASN.1 encoding. 134 Diameter messages are always carried over a protected transport such 135 as SCTP with DTLS or TCP with TLS, where the purpose is to mutually 136 authenticate Diameter Peers in protection of in-transit data against 137 rogue alterations and to conceal sensitive data from similarly 138 undesirable parties. These security requirements are alternatively 139 met by the Kerberos framework when AuthorizationData is used to carry 140 the Diameter frames. 142 Diameter distinguishes between sessions and connections. Connections 143 represent coherent message carriers such as TCP or SCTP connections, 144 whereas a session specifies a conceptual relationship that may span 145 multiple connections. Each connection may carry multiple sessions. 147 Requests over one connection may even be responded to over another. 148 For the purposes of Diameter, passing messages via Kerberos can be 149 viewed as an alternative form of connection; the collaboration 150 between KDC and services can be considered a connection, consisting 151 of a multitude of individual packages but together forming a coherent 152 message carrier. 154 The average Diameter exchange is a request/response interaction 155 between a resource requesting access and an oracle granting or 156 withholding it. This model does not fit well on the Kerberos system, 157 when the KDC is an intermediate. A modified form does hold; the 158 client may request certain kinds of access in a Diameter frame, and 159 the KDC may filter, modify and pass it on. It is also possible for 160 the KDC to use just the client identity to state privileges that are 161 granted to it. 163 An AuthorizationData field with a Diameter message reaching the 164 service from an known-aware KDC can be treated as a pro-active hint, 165 to prepare an answer that might come up when interpreting a service 166 request. This is possible because the KDC is always aware of the 167 service being targeted by a requested ticket. The hint provided 168 would stand for the entire duration of the service ticket, 169 effectively turning such tickets into client-held caches of their 170 authorisations. 172 Diameter connections must start interactions with a Capabilities 173 Exchange. This specification answers that with a default setup with 174 the Network Access Application [RFC7155] and possible overrides to 175 take place during administrative setup, such as during the creation 176 of service keys or the establishment of realm crossover. This 177 loosely addresses the requirement for Capabilities Exchange. 179 This looseness is warranted because the customary need for a 180 Capabilities Exchange is not fully applicable to the use of Diameter 181 messages in AuthorizationData, not even when crossing realms. First, 182 this can be used as a pro-active mechanism and it is generally safe 183 to ignore any misunderstood Diameter messages. Second, tickets tend 184 to be cached for a day, which makes their generation less resource- 185 demanding. Third, the purpose can help avoid traditional Diameter 186 traffic, thus limiting the danger of a lot of spurious network 187 traffic. 189 Peers that process Kerberos messages should not be considered 190 Diameter processing nodes, as they may be just passing traffic, 191 except for the end points that produce and consume Diameter messages 192 in AuthorizationData. By default, a KDC will pass AuthorizationData 193 that the client supplies as-is, though it reserves the right to make 194 modifications. This means that clients under a KDC unaware of 195 Diameter-formatted AuthorizationData might send any claims they like 196 to a foreign realm, and that the KDC cannot be considered a Diameter 197 end point unless it adds a proof of origination. 199 3. Use with Realm Crossover 201 When crossing over between realms under independent administrative 202 control, matters of trust and security arise. This has implications 203 for the interpretation of the AuthorizationData fields, including the 204 form described herein. 206 To overcome this problem, the client KDC must use CAMMAC [RFC7751] to 207 protectively wrap the AuthorizationData for AD-DIAMETER. Trusting 208 services should validate the origin to be the intended KDC. This 209 usually means that the KDC of the service realm validates the AD- 210 DIAMETER data as having originated from the client realm. 212 With the possible exception for manual overrides, it is not safe to 213 rely on any other delivery form of AD-DIAMETER data from another 214 realm. 216 4. Security Considerations 218 This specification suggests some leniency in terms of attempting to 219 access Diameter services that may extend beyond available 220 capabilities. To mitigate any risk, unrecognised messages could be 221 silently ignored. In other uses of Diameter, this would instead 222 cause an explicit error message. As long as no actions are taken on 223 unrecognised content, this should not impact security. 225 Diameter messaging parties must take responsibility for what they 226 send. Kerberos KDCs may pass AuthorizationData without looking, so 227 any such fields with AD-DIAMETER data must be sent under CAMMAC 228 protection to prove the agreement of the originating KDC. 230 During realm crossing, privileges may be passed in from a KDC of 231 another realm. It is important for any service realm to be mindful 232 of this. Whether this concern is implemented in individual services 233 or generally dealt with in the realm's KDC is a local operational 234 choice of the service realm; the KDC for the service realm always 235 participates in realm crossover, because it needs to supply the 236 service ticket to the client that crosses over. 238 During realm crossing, the client's KDC releases a crossover ticket 239 to reach a remote realm. The information contained in this ticket's 240 AuthorizationData may be visible to all services in the remote realm, 241 and is therefore a privacy concern. It may be necessary to either 242 supply only generic or selected information (such as descriptive 243 attributes) or use only one or a few foreign services per realm. 245 5. IANA Considerations 247 When IANA takes on the registration of AuthorizationData tags, it 248 will take the following allocation into account: 250 TODO 252 6. Normative References 254 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 255 Kerberos Network Authentication Service (V5)", RFC 4120, 256 DOI 10.17487/RFC4120, July 2005, 257 . 259 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 260 Ed., "Diameter Base Protocol", RFC 6733, 261 DOI 10.17487/RFC6733, October 2012, 262 . 264 [RFC6806] Hartman, S., Ed., Raeburn, K., and L. Zhu, "Kerberos 265 Principal Name Canonicalization and Cross-Realm 266 Referrals", RFC 6806, DOI 10.17487/RFC6806, November 2012, 267 . 269 [RFC7155] Zorn, G., Ed., "Diameter Network Access Server 270 Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, 271 . 273 [RFC7751] Sorce, S. and T. Yu, "Kerberos Authorization Data 274 Container Authenticated by Multiple Message Authentication 275 Codes (MACs)", RFC 7751, DOI 10.17487/RFC7751, March 2016, 276 . 278 Appendix A. Acknowledgements 280 Thanks to the Kerberos list at MIT and especially Greg Hudson, for a 281 lot of information about Kerberos and GSSAPI. 283 This work was conducted as part of the InternetWide.org project, and 284 aims to support authorisation data that crosses over between 285 platforms and realms. Implementation projects under this 286 architecture are named ARPA2 projects. 288 We thank NLnet foundation and SURFnet for funding (parts of) this 289 work. 291 Author's Address 293 Rick van Rein 294 ARPA2.net 295 Haarlebrink 5 296 Enschede, Overijssel 7544 WP 297 The Netherlands 299 Email: rick@openfortress.nl