Individual Contribution Kaushik Narayan Internet-Draft HCL-Cisco Category :Experimental October 2001 Diameter Strong Security Extension using GSSAPI v2 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The distribution of this memo is unlimited. It is filed as , and expires April 2002. Please send comments to the author (kaushik@cisco.com). Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract The Diameter base protocol defines message integrity and AVP encryption using static symmetric transforms to secure the communication between two Diameter nodes. The base protocol also defines a Diameter proxy server, that forwards requests to other servers when it detects that a given request cannot be satisfied locally. Kaushik expires April 2002 [Page 1] Internet-Draft March 2001 The ROAMOPS Working Group has defined a requirement that needs the Diameter servers communicating through the proxy to be able to provide for end-to-end AVP integrity and confidentiality, making it difficult for the proxy to be able to modify, and/or be able to view sensitive information, within the message. The Mobile-IP and NASREQ Working Groups have stated that strong authentication is a requirement for AAA data, such as accounting records. This Diameter extension specifies how strong AVP authentication, integrity and encryption can be done using by keys negotiated using Kerberos v5. Table of Contents 1.0 Introduction 2.0 GSSAPI Overview 3.0 GSS Algorithm 4.0 Command-Codes Values 4.1 E2E-GSS-SA-Setup-Request (EGSSR) Command 4.2 E2E-GSS-SA-Setup-Answer (EGSSA) Command 5.0 Usage Scenario with Kerberos v5 GSSAPI mechanism 6.0 Deployment Issues 7.0 Strong Security AVPs 7.1 GSS-Data AVP 7.2 GSS-Token AVP 8.0 Result Code AVP Values 9.0 IANA Considerations 10.0 Security Considerations 11.0 References 12.0 Authors' Addresses 1.0 Introduction The Diameter base protocol [1] defines message integrity and AVP encryption using symmetric transforms to secure the communication between two Diameter nodes. The base protocol also defines a Diameter proxy server, that forwards requests to other servers when it detects that a given request cannot be satisfied locally. The ROAMOPS Working Group has defined a requirement in [10] that allows for the Diameter servers communicating through the proxy to be able to provide for end-to-end AVP integrity and confidentiality, making it difficult for the proxy to be able to modify and see sensitive information within the message. The Mobile-IP and NASREQ Working Groups have stated in [6, 7, 8] that non-repudiation is a requirement for AAA data, such as accounting records. Kaushik expires April 2002 [Page 2] Internet-Draft March 2001 When a chain of proxies use hop-by-hop security, each node in the proxy chain MUST recompute the Integrity-Value-Check (ICV) [1], making it easy for a malicious proxy to modify information in a Diameter message. It is virtually impossible for the rest of the nodes in the proxy chain to know that the message was modified in mid-stream. Figure 1 shows an example of such a network, where DIA3 modifies the contents of "foo" in both the request and the response. (Request) (Request) (Request) [AVP(foo)=x] [AVP(foo)=x] [AVP(foo)=y] +------+ -----> +------+ -----> +------+ -----> +------+ | | | | | | | | | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 | | | | | | | | | +------+ <----- +------+ <----- +------+ <----- +------+ (Answer) (Answer) (Answer) [AVP(foo)=b] [AVP(foo)=b] [AVP(foo)=a] Figure 1: Proxy Chain This document describes how strong authentication and encryption can be provided in the Diameter protocol, by employing security services provided by GSSAPI. GSSAPI would be use for key negotiation between Diameter peers. In the example provided in Figure 1, the originator of the request and response adds a digital signature that covers a set of AVPs within the message. The protected AVPs MUST NOT be changed by an intermediate proxy server (DIA2, DIA3), since the signature validation performed by the end server would fail. The Extension number for this draft is two (2). This value is used in the Extension-Id AVP as defined in [1]. This specification makes use of the 'P' bit in the AVP Header, which is defined in [2]. 2.0 GSSAPI Overview In GSS, client and server interact to create a "security context". Creating a security context involves a negotiation between client and server. Once a context has been established, it has a finite lifetime for which it can be used to secure messages. Client and server MUST be locally authenticated and have acquired default credentials before using this protocol as specified in Section 1.1.1 "Credentials" in RFC 2743 [RFC2743]. Kaushik expires April 2002 [Page 3] Internet-Draft March 2001 In GSS, establishing a security context involves the passing of opaque tokens between the client and the server. The client generates the initial token and sends it to the server. The server processes the token and if necessary, returns a subsequent token to the client. The client processes this token, and so on, until the negotiation is complete. The number of times the client and server exchange tokens depends on the underlying security mechanism A completed negotiation results in a context handle. A unique context is required for each server to which the client sends secure messages. A context is identified by a context handle. A client maintains a mapping of servers to handles, (target_name, key_name, context_handle) The value key_name also identifies a context handle. The context_handle WOULD be used to provide protection for Diameter AVPs. The GSS Security Context is synonomous to the Security Assocation (SA) for the purpose of this discussion. 3.0 GSS Algorithm When a Diameter node is about to send a messsage which MAY use strong security, it must determine whether to use the strong security service or not. The Diameter node WOULD first check whether a context handle has been cached for the given destination realm. The cached context handle would be used for strong security in case it has not expired. In the present discussion we assume that the Diameter node does not have cached any information. This draft makes use of the Diameter E2E-GSS-SA-Setup-Request (EGSSR) and E2E-GSS-SA-Setup-Answer (EGSSA) messages defined in section 4 to establish whether strong security is required and if so, for which AVPs. Kaushik expires April 2002 [Page 4] Internet-Draft March 2001 Step 1: The originating node sends the EGSSR message to the destination node (a server in the destination realm). The originating node calls GSS_Init_sec_context, using the most recent reply token received from desitination node during this exchange, if any. It MUST set the integ_req_flag to "true" to request that per-message integrity protection be supported for this context. and it MUST pass the TTL for this SA in lifetime_req parameter. The orginating node would generate an error in the following cases * If the resulting major_status code is GSS_S_COMPLETE and the integ_avail flag is not true, then per-message integrity protection is not available. * If the call does not produce a GSS token of non-zero length. In case of an error, the originating node cannot obtain end-to-end strong security. The originating node sends the EGSSA message with a valid GSS token to the destination node in the following cases * If the resulting major_status code is GSS_S_CONTINUE_NEEDED, The destination node will reply back with a new token to be provided to GSS_Init_sec_context. * If GSS_Init_sec_context returns a GSS_S_COMPLETE. In this case the security context has been succesfully established at the orginating node and the processing on the destination node continues with Step 3. This EGSSR message WOULD contain - the token returned from the GSS_Init_sec_context call. - a list of AVPs that expected to be protected (and how) for this realm Kaushik expires April 2002 [Page 5] Internet-Draft March 2001 Step 2: The destination node calls GSS_Accept_sec_context, using the token received in the EGSSR message from originating node. The destination node WOULD reply back with an EGSSA message containing the GSS token in the following cases * If the resulting major_status code is GSS_S_COMPLETE, the security context has been established succesfully on the destination node and processing continues with Step 3. * If the resulting major_status code is GSS_S_CONTINUE_NEEDED, the processing will continue with Steps 1 and 2 until GSS_S_COMPLETE. In case the GSS_Acccept_Sec_Context does not produce a GSS token of non-zero length, the destination node would send an error message in the EGSSA message. This EGSSA message WOULD contain - the token returned from the GSS_Accept_sec_context call. - a list of AVPs that expected to be protected (and how) for this realm Step 3: The security context has been succesfully established at the Diameter node. The Diameter node can now obtain security services using the context handle, the GSS_Wrap method would be used for confidentiality protection and GSS_GetMIC would be used for integrity protection. The context handle would be valid until TTL set by the destination node expires. Callers would be returned GSS_S_CONTEXT_EXPIRED in case they call GSS_Wrap or GSS_GetMIC after TTL expiration. The list of AVPs to be protected would be carried in the Expected-Signed-AVP and Expected-Encrypted-AVP AVPs defined in [2]. 4.0 Command-Codes Values This section defines new Command-Code [1] values that MUST be supported by all Diameter implementations that conform to this specification. The following Command Codes are currently defined in this document: Command-Name Abbrev. Code Reference ------------------------------------------------------------ E2E-GSS-SA-Setup-Request EGSSR 320 4.1 E2E-GSS-SA-Setup-Answer EGSSA 320 4.2 Kaushik expires April 2002 [Page 6] Internet-Draft March 2001 4.1 E2E-GSS-SA-Setup-Request (EGSSR) Command The E2E-SA-Setup-Request command, indicated by the Command-Code field set to 320 and the 'R' bit set in the message flags field, is sent by a Diameter node to establish a Diameter GSS based End-to-End Security Association. ::= < Diameter-Header: 320, R > * [ Expected-Signed-AVP ] * [ Expected-Encrypted-AVP ] [ GSS-Token ] 4.2 E2E-GSS-SA-Setup-Answer (EGSSA) Command The E2E-SA-Setup-Answer command, indicated by the Command-Code field set to 304 and the 'A' bit set in the message flags field, is sent by a Diameter node in response to an EGSSR message. ::= < Diameter-Header: 320, A > * [ Expected-Signed-AVP ] * [ Expected-Encrypted-AVP ] [ GSS-Token ] 5.0 Usage Scenario with Kerberos v5 GSSAPI mechanism. The Kerberos v5 GSSAPI mechanism SHOULD be used in the is used with mutual authentication. The originating Diameter node SHOULD possess a valid cross realm TGT which forms the default credentials. Acquisition of cross realm TGTs and models for cross realm trust are discussed in section 5.0. The Kerberos v5 service principal would be of the form diameter@homeserver.HOMEREALM.COM. The GSS_Init_Sec_Context would acquire the service principal ticket from the KDC in case there isn't a valid ticket present in the credentials cache. In routing the Diameter Request to the destination Diameter node, the NAI is typically used, as described in RFC 2486. The originating Diameter node (NAS) would also need the hostname of the destination Diameter node (homeserver) to construct the End-to-End service principal. The hostname and port of a destination Diameter node (homeserver) WOULD be determined by quering DNS, using either an address record approach, or an SRV record approach. Remote realm Kerberos Key Distribution Centres(KDC) can either be statically configured or can be discovered dynamically. The internet draft "draft-ietf-cat-krb-dns-locate-02.txt" suggests a method of dynamic discovery of the KDC for a remote realm. Kaushik expires April 2002 [Page 7] Internet-Draft March 2001 The key exchange of the Kerberos GSS mechanism would happen as follows. originating node (NAS) destination node (homeserver) ---------------------- ----------------------------- GSS_Init_sec_context(TTL,integ_req_flag) returns GSS_S_CONTINUE_NEEDED, output_token EGSSR --------> Expected-Signed-AVP Expected-Encrypted-AVP GSS-Token (output_token) GSS_Accept_sec_context(input_token) returns GSS_S_COMPLETE, output_token <-------- EGSSA Expected-Signed-AVP Expected-Encrypted-AVP GSS-Token (output_token). GSS_Init_sec_context(input_token) returns GSS_S_SUCCESS. At the end of the above exchange, the homeserver and NAS would have mutually authenticated each other and both the Diameter nodes would have a context handle which would provide the security services to both Diameter nodes. The key exchange of the Kerberos GSS mechanism and the SA creation WOULD take one round trip. 6.0 Deployment Issues A valid cross-realm TGT should be present on the originating Diameter node (NAS) to create a security associations with destination Diameter nodes (homeserver) in that realm. The initial TGT can be obtained manually during bootup of the originating node (NAS). Alternatively PKINIT can be employed wherein the homeserver's public key certificate WOULD be used in the initial authentication exchange with the local KDC. Cross realm trust in Kerberos can be established in multiple ways. The simplest way is to maintain separate keys for every realm which wishes to exchange authentication information with another realm (which implies n(n-1) keys). Kerberos v5 support transitive trust which allows hierarchichal arrangement of realms for better scalability. Kaushik expires April 2002 [Page 8] Internet-Draft March 2001 Another option available is PKCROSS which utilizes a public key infrastructure (PKI) [X509] to simplify the administrative burden of maintaining cross-realm keys. PKCROSS take advantage of the distributed trust management capabilities of public key cryptography for establishing cross realm trust. The model proposed in this draft has the NAS as the GSS client and the Diameter homeserver as the GSS server. 7.0 Strong Security AVPs This section contains AVPs that are used to establish a Diameter End-to-End Security Association. +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST|MAY | Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| GSS-Data 350 6.1 Grouped | M | P | | V | N | GSS-Token 351 6.2 OctetString| M | P | | V | N | 7.1 GSS-Data AVP The GSS-Data AVP (AVP Code 350) is of type Grouped and contains the AVPs which are required for End to End security. The grammar for the grouped Data field is defined is: GSS-Data = Digest ptextlen Encrypted-Data Digest = ; the output token of GSS_GetMIC call which provides e2e integrity protection and data origin authentication for Diameter AVPs. ptextlen = ; Plaintext-Data-Length. Encrypted-Data = ; the output token of the GSS_Wrap call which provides confidentiality for Diameter AVPs. +---------------------------------------------------------------+ | AVP Header (AVP Code = 350) | +---------------------------------------------------------------+ | Digest AVP | +---------------------------------------------------------------+ | Plaintext-Data-Length AVP | +---------------------------------------------------------------+ | Encrypted-Data AVP | +---------------------------------------------------------------+ Kaushik expires April 2002 [Page 9] Internet-Draft March 2001 7.2 GSS-Token AVP The GSS-Token AVP (AVP Code = 351) is of type OctetString. This AVP carries the GSS token exchanged during context initialization. 8.0 Result-Code AVP Values This section defines new Result-Code [1] values that MUST be supported by all Diameter implementations that conform to this specification. 9.0 IANA Considerations The Packet Type Codes, Attribute Types, and Attribute Values defined in this document are registered by the Internet Assigned Numbers Authority (IANA) from the Diameter name spaces. 10.0 Security Considerations This draft determines whether to use Kerberos purely on the basis of the existence or non-existence of a Kerberos service principal. This presents an opportunity for a downgrade attack wherein because an attacker can spoof an error message from the KDC and make the Diameter client not use end to end security which would compromise end to end security. Implementations should provide users with a policy knob which allow Diameter clients to throw an error in case they encounter an error while acquiring the service principal ticket from the KDC. 11.0 References [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "Diameter Base Protocol", draft-calhoun-diameter-17.txt, IETF work in progress, September 2000. [2] P. Calhoun, W. Bulley, S. Farrell, "Diameter Strong Security Extension", draft-calhoun-diameter-strong-crypto-07.txt (work in progress), March 2001. Kaushik expires April 2002 [Page 10] Internet-Draft March 2001 [3] J. Linn, "Generic Security Service Application Program Interface", Version 2, Update 1, RFC 2743, January 2000 [4] Kohl, J., and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work in progress, June 2000. [7] T. Hiller et al., "Cdma2000 Wireless Data Requirements for AAA", draft-hiller-cdma2000-AAA-02.txt, IETF work in progress, Sep- tember 2000. [8] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", draft-ietf- mobileip-aaa-reqs-04.txt, IETF work in progress, June 2000. [9] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol (OCSP)", RFC 2560, June 1999. [10] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999. [11] P. Calhoun, W. Bulley, "Diameter NASREQ Extension", draft- calhoun-diameter-nasreq-05.txt, IETF work in progress, September 2000. [12] P. Calhoun, C. Perkins, "Diameter Mobile IP Extensions", draft- calhoun-diameter-mobileip-11.txt, IETF work in progress, Sep- tember 2000. [13] Arkko, Calhoun, Patel, Zorn, "Diameter Accounting Extension", draft-calhoun-diameter-accounting-08.txt, IETF work in progress, 12.0 Author's Address Kaushik Narayan HCL-Cisco Offshore Development Centre, 158, NSK Salai, Vadapalani Chennai, Tamilnadu 600 026, India EMail: kaushik@cisco.com Phone: +091-44-3741939 Kaushik expires April 2002 [Page 11] Internet-Draft March 2001 13.0 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Kaushik expires April 2002 [Page 12]