ABFAB A. Perez-Mendez Internet-Draft R. Marin-Lopez Intended status: Experimental F. Pereniguez-Garcia Expires: September 2, 2012 G. Lopez-Millan University of Murcia Mar 2012 GSS-EAP pre-authentication for Kerberos draft-perez-abfab-eap-gss-preauth-01 Abstract This draft defines an alternative to the standard cross-realm operation in Kerberos, to allow users from an organization can obtain a TGT from the KDC of a different one, both belonging to the same AAA-based federation. This proposal makes use of the GSS-API pre- authentication for Kerberos and the GSS-API Mechanism for the Extensible Authentication Protocol to carry out the required functionality. Status of this Memo 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 http://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 September 2, 2012. Copyright Notice Copyright (c) 2012 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 (http://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 Perez-Mendez, et al. Expires September 2, 2012 [Page 1] Internet-Draft GSS-EAP preauth Mar 2012 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Elements of the architecture . . . . . . . . . . . . . . . . . 3 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Discovery of the KDC . . . . . . . . . . . . . . . . . . . 4 3.2. Pre-authentication with the KDC . . . . . . . . . . . . . 4 3.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Access to the Application Service . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4.1. AAA/EAP key management in Kerberos . . . . . . . . . . . . 10 4.2. Trust relationships . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Normative References . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Perez-Mendez, et al. Expires September 2, 2012 [Page 2] Internet-Draft GSS-EAP preauth Mar 2012 1. Introduction Kerberos [RFC4120] is becoming one of the most widely deployed protocols for authentication and key distribution, as it is integrated in different operating systems and network applications (FTP, SSH, HTTP...). However, Kerberos usage is typically used to control the access of the subscribers of a single organization, since Kerberos multi-domain (cross-realm) infrastructures are not usually deployed. This draft aims to provide an alternative to the typical cross-realm operation in Kerberos by making use of existing Authentication, Authorization and Accounting (AAA) infrastructures, the Extensible Authentication Protocol (EAP) [RFC3748] for authentication and the SAML [OASIS.saml-core-2.0-os] and XACML [OASIS.xacml-2.0-core-spec-os] for authorization. Since organizations typically deploy AAA infrastructures for controlling the access to services (especially network access service) in federated networks, the lack of a correct integration between Kerberos and AAA infrastructures limits the service access based on Kerberos only to service provider's subscribers, defeating the purpose of the network federations: to allow any end user in the federation to access any service deployed within it. In this document, we define a unified architecture to integrate existing AAA infrastructures with the service access control based on Kerberos. Specifically, we propose the user to perform a pre-authentication process with the visited KDC based on EAP, combining the use of the the GSS-API pre-authentication for Kerberos [I-D.perez-krb-wg-gss-preauth] and the GSS-API Mechanism for the Extensible Authentication Protocol [I-D.ietf-abfab-gss-eap]. Additionally, this solution also introduces authorization management based on the SAML and XACML standards. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Elements of the architecture Brief description of the elements in the proposed architecture. o End User. Integrates the functionality of Kerberos client, GSS initiator and EAP peer. o KDC. Integrates the functionality of Kerberos KDC, GSS acceptor and EAP authenticator. Perez-Mendez, et al. Expires September 2, 2012 [Page 3] Internet-Draft GSS-EAP preauth Mar 2012 o AAA server. Integrates the functionality of the EAP server. o Identity Provider. Generates authentication statements upon a request from the AAA server and attribute statements upon a request from the KDC. o Policy Decision Point (PDP). Manages the set of access control policies for the domain of the KDC and takes authorization decisions based on the provided information. o MetaData Service (MDS). Maintains a database of every service metadata within the federation. The MDS can be queried by any member of the federation to obtain information about other member's public service [OASIS.saml-metadata-2.0-os]. o Application Server. Provides a service valuable to the End User, whose access is controlled by means of the Kerberos protocol. 3. Operation 3.1. Discovery of the KDC In federated environments, where users move between different organizations, the specific location of the KDC in any visited domain should by dynamically discovered by the End User. This may be achieved by the use of DNS SRV RR queries as defined in [RFC4120] or the DHCPv6 protocol as defined in [I-D.sakane-dhc-dhcpv6-kdc-option]. 3.2. Pre-authentication with the KDC Once the KDC location is known by the End User, the pre- authentication process is performed as depicted (in a very simplified way) in Figure 1. A detailed description of these steps is provided following. Perez-Mendez, et al. Expires September 2, 2012 [Page 4] Internet-Draft GSS-EAP preauth Mar 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Visited | | Home | | Organization | | Organization | | +-+-+-+ +-+-+-+ | | +-+-+-+ +-+-+-+ | | | EU | | KDC | | | | AAA | | IdP | | | +-+-+-+ +-+-+-+ | | +-+-+-+ +-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | |AS_REQ(PA-GSS-TOK(EAP-Res))) | | |------------------->| | | | |Access-Request(EAP-Req) | | |----------------->| | | | | | | Acess-Challenge(EAP-Req) | | |<-----------------| | | | | | | KRB_ERROR(MORE_PRAUTH_NEEDED, | | | PA-FX-COOKIE, | | | PA-GSS-TOK(EAP-Req)) | | |<-------------------| | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | REPEAT N-TIMES UNTIL EAP METHOD IS COMPLETED | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | |AS_REQ(PA-GSS-TOK(EAP-Res), | | | PA-FX-COOKIE) | | |------------------->| | | | |Access-Request(EAP-Res) | | |----------------->| | | | |AuthnReq(username) | | |---------------->| | | | | | | | SAML Assertion| | | |<----------------| | | Access-Accept | | | |(EAP-Succ,Assertion,MSK) | | |<-----------------| | | | | | | +-+-+-+-+-+-+-+-+-+-+ | | | | Derive reply-key | | | | | based on MSK | | | | +-+-+-+-+-+-+-+-+-+-+ | | | | | | |AS_REP(PA-GSS-TOK(EAP-Succ), | | | enc-part, | | | TGT[Assertion]) | | |<-------------------| | | Perez-Mendez, et al. Expires September 2, 2012 [Page 5] Internet-Draft GSS-EAP preauth Mar 2012 Figure 1: EAP-GSS pre-authentication with the KDC 1. Kerberos client calls to GSS_Init_sec_ctx() to obtain the a GSS token to be sent to the KDC. Details on this process are described in [I-D.perez-krb-wg-gss-preauth]. The selected GSS mechanism is GSS-EAP, defined in [I-D.ietf-abfab-gss-eap]. 2. The GSS_Init_sec_ctx() call is treated by the GSS-EAP mechanism, which generates the actual GSS token following the specifications provided in [I-D.ietf-abfab-gss-eap]. Usually, this GSS token will contain an EAP response message. At this level, the GSS-EAP mechanism will use the EAP identity of the End User. 3. Once the Kerberos client has obtained the GSS token, it is encapsulated into a PA-GSS-TOKEN pre-authentication data element and included into the KRB_AS_REQ message (as specified in [I-D.perez-krb-wg-gss-preauth]). The user may belong to a different organization than the KDC and, therefore, its client name may not be found in the KDC's local database. To avoid the generation of an error of type KDC_ERR_C_PRINCIPAL_UNKNOWN, the Kerberos client sets the cname field of the KRB_AS_REQ message to a new fixed value, WELLKNOWN:FEDERATED, following the model proposed in [RFC6111]. In this manner, the KDC is warned that the End User belongs to the federation and not local verification of credentials should be done. 4. On the reception of the KRB_AS_REQ message, the KDC omits the local database lookup of the client name, since WELLKNOWN: FEDERATED is indicated. Then, the KDC calls the GSS_Accept_sec_ctx() function, as described in [I-D.perez-krb-wg-gss-preauth], to process the GSS token received in the PA-GSS-TOKEN pre-authentication data element. 5. The GSS_Accept_sec_ctx() call is treated by the GSS-EAP mechanism, which extracts EAP packet contained on it, determines the AAA server where it should be forwarded and encapsulates it into the proper AAA protocol (i.e. RADIUS or Diameter), as described in [I-D.ietf-abfab-gss-eap]. 6. The AAA server processes the EAP packet and generates a new EAP Request for the End User. If the response is an EAP Success, the process continues in step 10. Otherwise, the AAA server encapsulates the EAP packet into a AAA message and sends it to the KDC. Note: For simplicity, AAA proxies are not considered. More details are provided in [I-D.ietf-abfab-gss-eap]. Perez-Mendez, et al. Expires September 2, 2012 [Page 6] Internet-Draft GSS-EAP preauth Mar 2012 7. The GSS-EAP mechanism in the KDC processes the AAA message and generates a new GSS token with the obtained EAP request. 8. As a result of the call to the GSS_Accept_sec_ctx() function, the KDC obtains the GSS token, which is encapsulated into a new PA-GSS-TOKEN element and sent to the Kerberos client into a KRB_ERR message with code MORE_PREAUTH_DATA_REQUIRED as specified in [I-D.perez-krb-wg-gss-preauth]. This KRB_ERR message also contains a PA-FX-COOKIE element where the KDC introduces the value of the context handle obtained after the call. 9. The Kerberos client processes the KRB_ERR message, obtains the GSS token and calls to the GSS_Init_sec_ctx() function. The process continues as defined in step 1. 10. If the AAA server determines that the authentication has been completed, before sending the proper message to the KDC it contacts with its local IdP to obtain an SAML Authentication Statement. This is accomplished by sending a SAML AuthnRequest message to the IdP, indicating the EAP identity as the value of the Subject. This message is generated following the SOAP-based authentication profile described in [LIBERTY.idwsf-authn-svc-v2.0]. Alternatively, the IdP could be collocated with the AAA server. In this case, this and the next step would be omitted as the AAA server could issue the SAML Assertion by itself. Another option would be that the KDC generates the SAML AuthnRequest instead of the AAA server, since it will be the ultimate consumer of the produced Assertion. 11. The IdP authenticates the user based on the trust established in the organization between the AAA server (acting as the attester) and the IdP, and generates a SAML Assertion in response. This Assertion, which contains an Authentication Statement, will be used to refer to this authentication process in the future (e.g. to request attributes). 12. The AAA server verifies the Authentication Statement and encapsulates the Assertion into an SAML-AAA attribute, following schema described in [I-D.ietf-abfab-aaa-saml]. Then it sends the AAA response message to the KDC including this attribute along with the EAP Success packet and the derived MSK. If the assertion length is big enough to make the RADIUS packet exceed the 4 KB limit, the RADIUS packet fragmentation solution described in [I-D.perez-radext-radius-fragmentation] would be applied. Perez-Mendez, et al. Expires September 2, 2012 [Page 7] Internet-Draft GSS-EAP preauth Mar 2012 13. The GSS-EAP mechanism processes the AAA response as described in [I-D.ietf-abfab-gss-eap]. The EAP identity is exported as initiator name. This name will also include the received Assertion as an attribute, following the specifications in GSS- naming [I-D.ietf-kitten-gssapi-naming-exts]. The MSK is used to derive the GMSK. 14. The KDC obtains, as a result of the last call to the GSS_Accept_sec_ctx(), the final GSS token, and the initiator name. As described in [I-D.perez-krb-wg-gss-preauth], the token is encapsulated into a PA-GSS-TOKEN, while the initiator name is used as the cname field in both, the KRB_AS_REP message and the TGT. Furthermore, the KDC obtains, using the GSS_Get_name_attribute(), the SAML Assertion. This Assertion is included in a new authorization data element (ADE) into the authorization_data field of the TGT. By this way, the TGS will receive the Assertion in the KRB_TGS_REQ. Following the specifications in [I-D.perez-krb-wg-gss-preauth], the KDC uses the GSS_Pseudo_random() call to generate the reply key with which encrypting the enc-part of the KRB_AS_REP message (Replacing-reply-key facility) 15. Finally, the Kerberos client processes the KRB_AS_REP message. As a first step, the PA-GSS-TOKEN is processed as specified in [I-D.perez-krb-wg-gss-preauth]. The GSS-EAP mechanism extracts the EAP packet from the token and derives the MSK and the GMSK. The Kerberos client uses the GSS_Pseudo_random() call to generate the reply key, and decrypts the enc-part of the KRB_AS_REP message. After that, the Kerberos client stores the TGT into the credentials cache associated to the identity indicated in the cname field. 3.3. Authorization With the TGT, the End User can request Service Tickets (ST) for the different services in the domain by means of a TGS exchange. In this process, the TGS can take an authorization decision based on the identity information of the End User, thanks to the authorization information (i.e. Assertion) the AS included in the TGT. Both the service and the client are completely agnostic of this authorization process, thus they do not require changes. A simplification of the process is outlined in Figure 2. A detailed description is provided below. Perez-Mendez, et al. Expires September 2, 2012 [Page 8] Internet-Draft GSS-EAP preauth Mar 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ | Visited | | Home | | Organization | Federation | Organizat | | | | | | +-+-+-+ +-+-+-+ +-+-+-+ | +-+-+-+ | +-+-+-+ | | | EU | | KDC | | PDP | | | MDS | | | IdP | | | +-+-+-+ +-+-+-+ +-+-+-+ | +-+-+-+ | +-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+ | TGS_REQ | | | | |(sname,TGT[Assertion]) | | | |---------------->| | | | | | MDS Query (user's home)| | | |----------------------->| | | | | | | | | MDS Response (IdP) | | | |<-----------------------| | | | | | | | |Attribute Query(pseudonym) | | |------------------------------------>| | | | | | | |Response(attributes) | | | |<------------------------------------| | | | | | | |Authz Decision Query | | | |(sname, attributes) | | | |------------>| | | | | | | | | |Authz Decision Resp | | | | (decision) | | | | |<------------| | | | TGS_REP (ST) | | | | |<----------------| | | | | | | | | Figure 2: Authorization process 1. The Kerberos client creates a new KRB_TGS_REQ message, following what is specified in [RFC4120]. This message transports the TGT obtained during the authentication phase. 2. The TGS (KDC) processes the KRB_TGS_REQ message as usual. When the TGS processes the authorization data element (ADE) containing the Assertion, it contacts with the federation's MDS to obtain the location of the End User's home IdP. This information is required in order to contact with the End User's IdP to request some user attributes to perform the authorization decision. Perez-Mendez, et al. Expires September 2, 2012 [Page 9] Internet-Draft GSS-EAP preauth Mar 2012 3. With the metadata information the TGS is able to contact with the End User's IdP directly. This contact is performed by means of a SAML Attribute Query message [OASIS.saml-core-2.0-os], indicating the pseudonym of the user included in the assertion as the Subject. 4. The IdP recognises the pseudonym and provides the requested attributes in a SAML Response containing one or more SAML Attribute Statements. 5. The TGS provides the gathered attributes to the local PDP, along with information about the resource (sname) and the action to be performed, using an XACML AuthzDecision Query message. With this information the PDP queries its local policy database and takes an authorization decision. This decision is provided to the TGS using a XACML AuthzDecision Response message. 6. If the decision is PERMIT, the TGS issues the ticket for the requested service. Otherwise, if the decision is DENY, the client is provided with a Kerberos error message and the ST is not delivered. There is one way of simplifying the authorization work-flow by allowing IdPs to return SAML Attribute Statements during the first step of the authorization phase. In this case, the AAA server will receive a SAML Attribute Statement holding the end user attributes along with the Authentication Statement in the Assertion. This way the MDS Query and the Attribute Query exchanges could be omitted, since the Assertion already contains the required information. However, this approach does not allow the IdP to discriminate what attributes should be returned based on the preferred services, because they are known in the KRB_TGS exchange. 3.4. Access to the Application Service With the ST, the user can access the Application Service using standard Kerberos, as described in [RFC4120] 4. Security Considerations 4.1. AAA/EAP key management in Kerberos The use of EAP for Kerberos pre-authentication has security implications, specially in key distribution and management. The security analysis described in [RFC4962] and [RFC5247] are applicable here. Indeed, intermediate AAA proxies placed between the KDC and the home AAA server can observe the distributed MSK that will be used Perez-Mendez, et al. Expires September 2, 2012 [Page 10] Internet-Draft GSS-EAP preauth Mar 2012 to derive the Kerberos secret key. However, the trust model in federated environments assumes that intermediate AAA proxies are trusted entities. Moreover, as [RFC4962] explains, some key wrapping techniques can be applied to provide confidentiality, integrity and replay protection to the distributed key material between each pair of AAA entities (e.g. AAA proxies). 4.2. Trust relationships This work assumes the existence of a transitive trust relationship for authentication between the involved domains thanks to the deployed AAA infrastructure. Besides, regarding the authorization process, it is generally assumed the use of a direct trust relationship, allowing the protection of SAML messages directly between domains (step 2 and 3). Usually PKI architecture are used to deploy this trust. Following this approach IdPs and KDCs should be fed with cryptographic material. Nevertheless, other approach can be followed to avoid the deployment of an additional infrastructure (e.g. PKI). We could leverage the transitive trust relationship defined by the deployed AAA infrastructure to perform safely the attribute recovery process by means of the AAA protocol. In this case, it is necessary to define new extensions to standard AAA protocols. 5. IANA Considerations This document has no actions for IANA. 6. Normative References [I-D.ietf-abfab-aaa-saml] Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding and Profiles for SAML", draft-ietf-abfab-aaa-saml-02 (work in progress), October 2011. [I-D.ietf-abfab-gss-eap] Howlett, J. and S. Hartman, "A GSS-API Mechanism for the Extensible Authentication Protocol", draft-ietf-abfab-gss-eap-04 (work in progress), October 2011. [I-D.ietf-kitten-gssapi-naming-exts] Johansson, L., Williams, N., Hartman, S., and S. Perez-Mendez, et al. Expires September 2, 2012 [Page 11] Internet-Draft GSS-EAP preauth Mar 2012 Josefsson, "GSS-API Naming Extensions", draft-ietf-kitten-gssapi-naming-exts-12 (work in progress), December 2011. [I-D.perez-krb-wg-gss-preauth] Perez-Mendez, A., Pereniguez-Garcia, F., Lopez-Millan, G., and R. Lopez, "GSS-API pre-authentication for Kerberos", draft-perez-krb-wg-gss-preauth-01 (work in progress), January 2012. [I-D.perez-radext-radius-fragmentation] Perez-Mendez, A., Lopez, R., Pereniguez-Garcia, F., Lopez- Millan, G., Lopez, D., and A. DeKok, "Support of fragmentation of RADIUS packets", draft-perez-radext-radius-fragmentation-01 (work in progress), February 2012. [I-D.sakane-dhc-dhcpv6-kdc-option] Sakane, S. and M. Ishiyama, "Kerberos Options for DHCPv6", draft-sakane-dhc-dhcpv6-kdc-option-13 (work in progress), December 2011. [LIBERTY.idwsf-authn-svc-v2.0] Hodges, J., Aarts, R., Madsen, P., and S. Cantor, "Liberty ID-WSF Authentication, Single Sign-On, and Identity Mapping Services Specification", Liberty Alliance liberty- idwsf-authn-svc-v2.0, 2006. [OASIS.saml-core-2.0-os] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core- 2.0-os, March 2005. [OASIS.saml-metadata-2.0-os] Cantor, S., Moreh, J., Philpott, R., and E. Maler, "Metadata for the Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March 2005. [OASIS.xacml-2.0-core-spec-os] Moses, T., "eXtensible Access Control Markup Language (XACML) Version 2.0", OASIS Standard xacml-2.0-core-spec-os, February 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Perez-Mendez, et al. Expires September 2, 2012 [Page 12] Internet-Draft GSS-EAP preauth Mar 2012 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007. [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008. [RFC6111] Zhu, L., "Additional Kerberos Naming Constraints", RFC 6111, April 2011. Authors' Addresses Alejandro Perez-Mendez (Ed.) University of Murcia Campus de Espinardo S/N, Faculty of Computer Science Murcia, 30100 Spain Phone: +34 868 88 46 44 Email: alex@um.es Rafa Marin-Lopez University of Murcia Campus de Espinardo S/N, Faculty of Computer Science Murcia, 30100 Spain Phone: +34 868 88 85 01 Email: rafa@um.es Perez-Mendez, et al. Expires September 2, 2012 [Page 13] Internet-Draft GSS-EAP preauth Mar 2012 Fernando Pereniguez-Garcia University of Murcia Campus de Espinardo S/N, Faculty of Computer Science Murcia, 30100 Spain Phone: +34 868 88 78 82 Email: pereniguez@um.es Gabriel Lopez-Millan University of Murcia Campus de Espinardo S/N, Faculty of Computer Science Murcia, 30100 Spain Phone: +34 868 88 85 04 Email: gabilm@um.es Perez-Mendez, et al. Expires September 2, 2012 [Page 14]