| Network Working Group | R. Van Rein |
| Internet-Draft | ARPA2.net |
| Intended status: Experimental | October 20, 2018 |
| Expires: April 23, 2019 |
Diameter Messages in Kerberos5 AuthorizationData
draft-vanrein-krb5-authzdata-diameter-00
The Kerberos5 infrastructure is concerned with authentication, but it can also carry AuthorizationData in a variety of formats. Diameter is an extensible standard for the expression of authorisation information. This specification defines an embedding of Diameter data in the AuthorizationData fields of Kerberos5.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2019.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Kerberos5 [RFC4120] is a single-signon system that automatically supplies users with authentication tickets to individual services. Such tickets tend to last as long as a maximum user session, usually up to a day. They are provided by a central realm service known as the Key Distribution Center or KDC.
Though designed for authention rather than authorisation, KDC exchanges lend themselves well to facilitate both. The message formats can carry AuthorizationData consisting of a numerical tag and data to be interpreted according to that tag. This specification adds a tag value to describe AuthorizationData holding Diameter protocol messages.
AuthorizationData can be included in requests to the KDC, and the KDC can include AuthorizationData in a ticket. When requesting a service ticket from the KDC, a single-signon ticket with possible AuthorizationData is attached to that request. All this data is protected in transit; requests to the KDC are encrypted with the TGT secret or a sub-secret; tickets pass it to a service using a key shared between the server and KDC.
Diameter frames [RFC6733] hold a list of Attribute-Value Pairs (AVP), with optional nesting into group AVPs. The format is easily parsed and applications exist (or can be defined) to capture a class of usage scenarios. Among the existing applications is a network access application that lends itself for most authorisation applications.
The purpose of using Diameter in this place is to employ the existing communication infrastructure of Kerberos to pass authorisation settings between hosts. The standardised format simplifies access to services in foreign realms; this is useful to the InternetWide.org purpose to Bring Your Own IDentity (BYOID), which requires passing standardised authentication and authorisation information between collaborating but otherwise independent parties.
Diameter messages consist of a header choosing an application, followed by the AVPs that are meaningful within that application. The header guides the interpretation of the AVPs and is therefore a meaningful part in proper understanding of the exchange. This is why inclusion of Diameter as Kerberos AuthorizationData must not be limited to a set of AVPs but instead include a header.
Diameter messages are always carried over a protected transport such as SCTP with DTLS or TCP with TLS, where the purpose is to mutually authenticate Diameter Peers in protection of in-transit data against rogue alterations and to conceal sensitive data from similarly undesirable parties. These security requirements are alternatively met when AuthorizationData is used to carry the Diameter frames.
Diameter makes a distinction between sessions and connections. Connections represent coherent message carriers such as TCP or SCTP connections, whereas a session is more conceptual relationship that may span multiple connections and connections may carry multiple sessions. Requests over one connection may even be responded to over another. For the purposes of Diameter, passing messages through Kerberos can be viewed as an alternative form of connection; the collaboration between KDC and services can be considered a connection, consisting of a multitude of individual packages but together forming a coherent message carrier.
A normal exchange under Diameter is a request leading to a response. This can be established by inclusion of a request in a message going to a KDC, and a response coming out of it. We can also imagine responses to be supplied as a pro-active hint, to prepare an answer that might come up when interpreting a service request. This is possible because the client KDC is asked for a service ticket, allowing it to preview upcoming inquiries. The hint provided would stand for the entire duration of the service ticket, effectively turning such tickets into client-held caches of their authorisations.
Diameter connections must start interactions with a Capabilities Exchange. This specification answers that with a default setup with the Network Access Application [RFC7155] and possible overrides to take place during administrative setup, such as during the creation of service keys or the esstablishment of realm crossover. This looseley addresses the requirement for Capabilities Exchange.
The looseness is warranted because the customary need for a Capabilities Exchange is not fully applicable to the use of Diameter messages in AuthorizationData, not even when crossing realms. First, this can be used as a pro-active mechanism and it is generally safe to ignore any misunderstood Diameter messages. Second, tickets tend to be cached for a day, which makes their generation less resource-demanding. Third, the purpose can help avoid traditional Diameter traffic, thus limiting the danger of a lot of spurious network traffic.
Peers that process Kerberos messages should not be considered Diameter processing nodes, as they may be just passing traffic, except for the end points that produce and consume Diameter messages in AuthorizationData. Intermediate nodes may choose to process data though; for instance, during realm crossover the KDC of the service domain may remove authorisations that it does not find acceptable; the service may assume that it's realm is managed thusly. In general however, Kerberos defaults to passing AuthorizationData without change, meaning that Kerberos nodes cannot be held accountable for Diameter message content that it does not interpret.
This section is not normative; it serves to present context.
The following patterns are proposed for the InternetWide.org project, which aims to support secure and private interactions across realm boundaries for standard Internet protocols, including but certainly not limited to HTTP.
A general principle in the InternetWide Architecture is that users can Bring Your Own IDentity (BYOID) which is implemented with names with a local part and a domain part, basically like an email address or Netword Access Identifier. When crossing over to a remote realm, the intention is to allow a change to an alias that may be specific to that remote realm, thus allowing better control of online presence.
The InternetWide Architecture treats user services such as email and web as what Diameter calls Network Access Servers; they grant access to a facility, and need authorisation from the client's home realm. Diameter was designed to allow this across realms, and the inclusion of these forms in Kerberos tickets can greatly improve the scalability of such interactions.
The Kerberos mechanism is very efficient for use across realms, as is required under BYOID. Other current mechanisms tend to be less efficient due to:
In contrast, the proposed AuthorizationData used in Kerberos with realm crossover permits:
At the start of a session, a user logs in to the KDC for his realm. During the day, service tickets are requested. When the KDC needs to, it will forward the user to a remote realm through realm-crossing tickets, that the user follows using current Kerberos semantics [RFC6806].
For services in serviced realms, the KDC can insert dedicated authorisation information into requested service tickets.
The KDC cannot be configured to grant the supply of information to remote realms during the dissimination of realm-crossing tickets. Such information should not be specialised for a service name found in the request that caused it to release a realm-crossing ticket, because clients tend to cache these tickets and thus be deprived of this refinement for future use in the same realm. It is however possible to supply more kinds of information, or generally usable information, in such realm-crossing tickets.
The KDC of a service realm may prune information that does not apply, or is considered improper, for a service for which it received a request. This can be included into a specific ticket for a specific service. Some authorisation information during realm crossover is the prerogative of the client's KDC, other information is the prerogative of the service's KDC. Identity is a good example of client-sided control, whereas rights to write to a resource tend to be decided about on the service side. The InternetWide Architecture envisions standardised contracts between client and service realms that may enhance the information that could pass.
A targeted service can retrieve authorisation information from a service ticket, and be sure that it came from the KDC that constructed this ticket. In case of a user from a realm that is not local to the service's realm, the service may derive trust from any filtering that it knows is being done in the KDC for the service realm.
This section is not normative; it serves as an example.
Shell services are often made available through OpenSSH [RFC4251] and it is common to provide services (such as file transfer) as well as tunneling (such as to a server port behind a firewall). Kerberos access to these services take the form of rather general "host" tickets that is also used for several other purposes on the same host.
The multitude of access opportunities with one ticket calls for some restriction, but a change of the ticket naming convention is not practical. Additional content describing authorised purposes is. Diameter messages can be useful to accommodate this. It may also help to provide access to shared environments, where each client is given a different kind of access profile. Even access to clients without a local account may be possible under such conditions.
Everyday setups of OpenSSH are isolated; it may use a plugin module to add Kerberos5 authentication and decide on the access and session properties. These setups tend to work in isolation without connectivity to a Diameter infrastructure, but having such data can nonetheless be beneficial.
This specification suggests some leniency in terms of attempting to access Diameter services that may not be as formally negotiated. This does mean that unrecognised messages should be silently ignored. In typical uses of Diameter, this would rather cause an explicit error message. As long as no actions are taken on unrecognised content, this should not impact security, however.
Diameter messaging parties must take responsibility for what they send. Kerberos peers pass AuthorisationData without looking, so these peers cannot be held responsible and should be viewed as communication channels, not Diameter peers.
During realm crossing, the right to setup certain authorisation fields may vary. It is important for any trusting realm to be mindful of this. Whether this concern is implemented in individual services or generally dealt with in the realm's KDC is an operational choice that can be made locally to the realm; the realm's KDC is involved in realm crossover at the time that a service ticket is requested by the foreign client.
During realm crossing, the client's KDC releases a general ticket for a remote realm. The information contained in this ticket's AuthorizationData may be visible to all services in the remote realm, and so is subject to privacy concerns. It may be necessary to either supply only generic information (such as descriptive attributes) or use only one or a few foreign services per realm.
When IANA takes on the registration of AuthorizationData tags, it will take the following allocation into account:
TODO
| [RFC4120] | Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005. |
| [RFC6733] | Fajardo, V., Arkko, J., Loughney, J. and G. Zorn, "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012. |
| [RFC6806] | Hartman, S., Raeburn, K. and L. Zhu, "Kerberos Principal Name Canonicalization and Cross-Realm Referrals", RFC 6806, DOI 10.17487/RFC6806, November 2012. |
| [RFC7155] | Zorn, G., "Diameter Network Access Server Application", RFC 7155, DOI 10.17487/RFC7155, April 2014. |
| [RFC4251] | Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006. |
This work was conducted as part of the InternetWide.org project, and aims to support authorisation data that crosses over between platforms and realms. Implementation projects under this architecture are named ARPA2 projects.