Internet Draft Sri Gundavelli Expiration: June 2000 Cisco Systems File: draft-sgundave-gssauth-cops-00.txt Siva Vaddepuri Novell Dave McNamee Cisco Systems Jonathan Trostle Cisco Systems COPS Extension for GSS-API based Authentication Support December 01,1999 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. Conventions used in this document 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]. Abstract This document defines a security mechanism for the COPS protocol based on Generic Security Service Application Program Interface framework [RFC 2078]. The COPS policy server (Policy Decision Point or PDP) and the policy client (Policy Enforcement Point or PEP) can use the security mechanism defined in this draft for mutual authentication and for exchanging integrity protected messages with replay protection. Gundavelli et al. [Page 1] INTERNET-DRAFT COPS Security Expires June 2000 Table of Contents 1. Introduction ................................................[ 2] 2. GSS-API Overview ............................................[ 4] 2.1 Establishing Security Context ............................[ 4] 2.2 Exchanging messages using the security context ...........[ 5] 3. Extensions to the COPS protocol .............................[ 5] 3.1 Key Exchange Object (C-Num = 17) .........................[ 5] 3.2 Security Control Message Object (C-Num = 18) .............[ 6] 3.3 Message Integrity Object (C-Num=16) ......................[ 6] 3.4 Error Object (C-Num = 8) .................................[ 7] 3.5 GSS Negotiation (GSS-Nego Message, PEP->PDP, PDP->PEP) ...[ 8] 3.6 GSS-Request (GSS-Req Message, PEP->PDP, PDP->PEP) ........[ 8] 4. Protocol Details ............................................[ 8] 4.1 Acquiring Credentials ....................................[ 8] 4.2 Establishing Security Context ............................[ 9] 4.3 Generating Signed Messages ...............................[12] 4.4 Validating Signed Messages ...............................[13] 4.5 Deleting Security Context ................................[13] 5. Security Considerations .....................................[13] 6. References ..................................................[14] 7. Acknowledgments .............................................[14] 8. Author's Address ............................................[14] 1. Introduction COPS protocol provides a security mechanism based on shared secret keys. This approach does not quite scale well. Issues with the Shared Secret Key Mechanism: (a) One of the problems with the shared secret key mechanism is the key distribution. Every PEP has to have a shared secret key with every PDP and this requires major administrative efforts. Additionally, these keys need to be replaced periodically. (b) In case of chaining, with PDP providing referrals, every PEP needs to have a shared key with every PDP. As the number of PEP's go up, the burden of key management increases multifold. (c) If the security of the PDP is compromised, then the security of the entire managed administrative domain is compromised. Why NOT IPSec ? IPSec was suggested as one of the security solution for COPS. IPSec uses IKE. IKE (Internet Key Exchange) is a key management protocol and is used for mutual authentication between two peers, for negotiating security services between them and for arriving at a common keying material. IKE supports several authentication methods Gundavelli et al. [Page 2] INTERNET-DRAFT COPS Security Expires June 2000 and in practice two of them are widely used. a) Pre-Shared Key Authentication This requires the keys to be manually configured at the peers. Distributing keys manually to the peers will have the same challenges as explained earlier in this section. b) Digital Signature Authentication Requires X.509 certificate infrastructure for the enterprise and PKI support on all the policy clients and policy servers. This requires configuration of certificates on all the policy clients and policy servers. Enterprises do have Kerberos infrastructure and most of the switching and routing devices do have Kerberos stack implemented on them. So, it is much more logical to leverage this infrastructure for Application peer to peer security. Besides, for arriving at common keying material between the two IKE peers, they first use Diffie-Hellman Exchange for securing the channel to do mutual authentication. DH Exchange is computationally intensive and may not be suitable for a light weighted protocol like COPS. Further, IPSec adds integrity protection at IP datagram level. Every COPS message may result in several IP datagrams due to the network layer fragmentation. Adding integrity checks for every IP datagram will have performance issues. GSS-API with Kerberos V5 Provider GSS-API framework is developed as an industry standard. This framework enables applications in a distributed network environment to be able to use the following key aspects of network security. - Authentication - Integrity - Confidentiality - Replay Protection This framework is designed to operate with any security and transport mechanism. An application client and server can use Kerberos or any other security provider underneath this GSS-API framework. An application developer using this GSS-API framework is relieved from the burden of creating and managing security infrastructure. The developer can leverage the security infrastructure such as key distribution center provided for the enterprise. The idea is to use GSS-API for COPS with the assumption that the underlying chosen authentication technology is capable of authenticating a client to a server using elements carried within a Gundavelli et al. [Page 3] INTERNET-DRAFT COPS Security Expires June 2000 single token, and for authenticating the server to the client (mutual authentication) with in a single returned token. However, the suggested underlying security mechanism for COPS is Kerberos V5. 2. GSS-API Overview The Generic Security Service Application Programming Interface [GSS API] provides security services to calling applications such as Mutual Authentication, Integrity Protection, Message confidentiality and Replay Detection. This interface allows a caller application to authenticate a principal identity associated with a peer application, and to apply security services such as confidentiality and integrity on a per-message basis. The client and the server using this interface must first establish a security context. Once, the security context is established the client and the server can have secure communication with all the below defined security features. - Mutual Authentication - Integrity Protection - Message Confidentiality GSS-API context establishment may take a number of token exchanges between the client and the server. The client and the server feed these tokens to their local GSS implementation and iterate until an error is encountered or a GSS-API context is established. 2.1 Establishing Security Context The following diagram illustrates the context establishment process between two applications trying to establish a security context using GSS-API layer with Kerberos V5 security provider. +-------------+ +------------+ | Client | ------ GSS Token ------>| Server | | | <----- GSS Token -------| | +-------------+ +------------+ | /|\ | | /|\ | \|/ | \|/ \|/ | \|/ gss_init_security_context() gss_accept_security_context() +-------------+ +------------+ | GSS-API | | GSS-API | | | | | +-------------+ +------------+ /|\ | | /|\ | \|/ \|/ | +-------------+ +------------+ | Kerberos V5 | | Kerberos V5| | | | | +-------------+ +------------+ Gundavelli et al. [Page 4] INTERNET-DRAFT COPS Security Expires June 2000 Once all these negotiations have completed between the two peers a security context is established. 2.2 Exchanging messages using the security context After the security context is established, the client and server can exchange integrity protected messages using the established security context. +-------------+ +-------------+ |Client/Server| ---- Message & MIC ----> |Server/client| | | | | +-------------+ +-------------+ | /|\ | /|\ \|/ | \|/ | gss_get_mic() gss_verify_mic() +-------------+ +-------------+ | GSS-API | | GSS-API | | | | | +-------------+ +-------------+ /|\ | | /|\ | \|/ \|/ | +-------------+ +-------------+ | Kerberos V5 | | Kerberos V5 | | | | | +-------------+ +-------------+ 3. Extensions to the COPS protocol In order to be able to use the GSS-API based security mechanism for COPS, new data objects and COPS operations have to be defined. This section covers the extensions to the COPS protocol for achieving authentication using GSS-API. 3.1 Key Exchange Object (C-Num = 17) A new class of information pertaining to transaction keys is defined for the value, C-Num = 17 (Key Exchange Object). This object follows the COPS common object format defined in Section 2.2 of the COPS protocol specification. The type of key exchange mechanism is identified by the value of C-Type field in the object header. C-Num = 17 C-Type = 1, GSSAPI-Mechanism The GSSAPI-Mechanism object contains information pertaining to GSS context establishment. The PEP and the PDP use this object as a vehicle for token exchanges. Gundavelli et al. [Page 5] INTERNET-DRAFT COPS Security Expires June 2000 +-------------+-------------+-------------+-------------+ | | // GSS-API Token // | | +-------------+-------------+-------------+-------------+ 3.2 Security Control Message Object (C-Num = 18) The Security Control message object is used by the PEP and PDP to exchange control information pertaining to the security contexts. C-Num = 18 C-Type = 1, GSS-Security Message Object This object includes a GSS operation code field that is 32-bit unsigned integer. +-------------+-------------+-------------+-------------+ | GSS-Operation Code | +-------------+-------------+-------------+-------------+ GSS-Operation Code: 1 = Delete Security Context 2 = Process GSS Error 3.3 Message Integrity Object (C-Num=16) A new sub type is added for encapsulating GSS-API signed per-message token. C-Num = 16, C-Type = 2, GSS-Signed This integrity object includes a sequence number that is a 32-bit unsigned integer used to avoid replay attacks. This Sequence Number has the same definition as it is in the Message Integrity Object with C-Type = 1, HMAC Digest. (Refer to Sec 2.2.16, COPS Draft). The use of this sequence number is optional. If the PEP while establishing the security context chooses to enable Replay Protection (provided the underneath security mechanism supports that feature), then both the peers can ignore this field in all the packets. The sequence number is initiated during an initial Client-Open Client-Accept message exchange and is then incremented by one each time a new message is sent over the TCP connection in the same direction. If the sequence number reaches the value of 0xFFFFFFFF, the next increment will simply rollover to a value of zero. This integrity object also has the GSS signed message token. Gundavelli et al. [Page 6] INTERNET-DRAFT COPS Security Expires June 2000 The GSS signature or the per-message token is generated for the entire COPS message starting with the COPS header up to the Sequence number of the Message Integrity object and not including the per-message token. The generated per-message token has to be encapsulated in the GSS-Signed message integrity object for sending it as a COPS message. The integrity object must be the last object in the COPS message. 0 1 2 3 +-------------+-------------+-------------+-------------+ | Sequence Number | +-------------+-------------+-------------+-------------+ | | // GSS Signed Message // | | +-------------+-------------+-------------+-------------+ 3.4 Error Object (C-Num = 8) C-Num = 8, C-Type = 1 A new error code (Error-Code = 16) is defined for all the GSS-API authentication errors. The sub-code field provides more specific GSS-API error code. Error-Code: 16 = GSS-API Authentication error Error Sub-Code: (Various GSS-API errors) 1 = GSS_S_CONTEXT_EXPIRED 2 = GSS_S_CREDENTIALS_EXPIRED 3 = GSS_S_NO_CONTEXT 4 = GSS_S_BAD_QOP 5 = GSS_S_GAP_TOKEN 6 = GSS_S_DEFECTIVE_TOKEN 7 = GSS_S_BAD_SIG 8 = GSS_S_DUPLICATE_TOKEN 9 = GSS_S_OLD_TOKEN 10 = GSS_S_UNSEQ_TOKEN If any of the COPS messages do not pass the message integrity check, a GSS-Req message (Explained in Sec 3.6) containing the Error Object with the appropriate Error Code should be sent to the peer. Gundavelli et al. [Page 7] INTERNET-DRAFT COPS Security Expires June 2000 3.5 GSS Negotiation Message (GSS-Nego Message, PEP->PDP, PDP->PEP) Op Code: 11 = GSS-Nego The GSS-Nego has the following format: ::= Establishing a security context between the PEP and the PDP involves the passing of opaque tokens between them. One of them initiates the security context and is accepted by the other. The GSS-Nego message can be used by the PEP and the PDP for exchanging the tokens in the process of establishing a security context. 3.6 GSS-Request Message (GSS-Req Message, PEP->PDP, PDP->PEP) Op Code 12 = GSS-Req The GSS-Req has the following format: ::= [] GSS-Req message can be used by the PEP and PDP for exchanging information pertaining GSS security operations. PEP or PDP when intending to close a security context with its peer can send GSS-Req message with the right GSS-Operation code notifying its peer of this action. This message can also be used for sending other GSS errors. 4. Protocol Details This section specifies how the PEP and the PDP can use GSS API for establishing a security context and how they can exchange integrity protected messages using this established security context. 4.1 Acquiring Credentials The PEP and PDP have to be locally authenticated and should have the valid credentials before establishing a security context. The PEP and the PDP can use gss_acquire_cred API to get a credential handle. Gundavelli et al. [Page 8] INTERNET-DRAFT COPS Security Expires June 2000 4.2 Establishing Security Context Establishing the security context requires GSS tokens to be exchanged between the two peers. Once all of these negotiations have been completed and the GSS context has been established, the GSS context handle can be used for the generation and verification of message signatures. Either side may send integrity protected data messages for the other side. 4.2.1 Client side of the security context establishment The PEP calls GSS_init_sec_context to establish a security context with the following security options. Mutual Authentication Message Integrity Protection Replay Detection (optional) If the underlying security mechanism doesn't support these options, then the PEP has to abort this context negotiation. This API is invoked in a loop until the security context is established or the API status code from this call indicates an error. The first call to the API generates a GSS token with an API status code. This token needs to be transferred to the PDP for it to proceed with the process of context establishment between the two peers. The API Status code indicates if the gss_init_sec_context API Call needs to be invoked again using the token received from the PDP. If the major_status (return code from the function) is an error code, then the PEP must abandon this protocol. The GSS context handle obtained from this procedure is unique to this GSS context negotiation and should be associated with the TCP connection to the target server. 4.2.1.1 Transmitting the token to the peer (PEP or PDP) A Key Exchange object (C-Type = GSS-API Mechanism) has to be created as defined in Sec 3.1. This object must contain the API returned GSS-API token. A GSS-Nego message also has to be created with this object for transmitting the token. This constructed COPS message must be sent like any other COPS message to its peer. 4.2.1.2 Receiving the token from the peer (PDP or PEP) A GSS-Nego message received from the peer will contain a Key Exchange Object. The GSS-API token must be extracted from this Key Exchange Object. Gundavelli et al. [Page 9] INTERNET-DRAFT COPS Security Expires June 2000 4.2.1.3 Sample Code /* Convert the service name of the GSS-API internal format */ server_name.value = "COPS-SVC/router.cisco.com@CISCO.COM" server_name.length = strlen (server_name.value); maj_stat = gss_import_name ( &min_stat, &server_name, gss_nt_service_name, target_name ); gss_ctx_id_t context_hd1 = GSS_C_NO_CONTEXT; .... input_token = GSS_C_NO_BUFFER; while (1) { maj_stat = gss_init_sec_context ( &min_stat, cred_hdl, &context_hdl target_name, desired_mech desired_services, desired_time, input_bindings, input_token, &actual_mech, output_token, &actual_service, &actual_items ); if (output_token->length != 0) { - There is a token for the PDP - Create a Key Exchange object using this token (output_token) and defined in Sec 3.2 of this document - Send GSS_Nego message with this Key Exchange object to PDP. } if (maj_stat & GSS_S_CONTINUE_NEEDED) { - Receive the GSS_NEGO message from the PDP - Retrieve the GSS token from the message for the PEP and assign it to the input_token input_token = /* .. token from the PDP */ } Gundavelli et al. [Page 10] INTERNET-DRAFT COPS Security Expires June 2000 if (maj_stat & GSS_S_COMPLETE) { - PEP and the PDP have successfully established the GSS context break; } if (GSS_ERROR (maj_stat)) { - Abandon the protocol break; } }; 4.2.2 Server side of the security context establishment The PDP calls GSS_accept_sec_context passing the GSS token it received from the PEP in the GSS-Nego message. Retrieving the GSS token from the GSS-Nego message is explained in Sec. 4.2.1.2. The call to this GSS_accept_sec_context API results in a token if mutual authentication is desired by both the peers. The PDP has to send this token to the PEP in the GSS-Nego message as explained in Sec. 4.2.1.1. If the return code from this API is an error, then the PDP must abandon this protocol. If the return code from this API is GSS_S_COMPLETE, a GSS security context is successfully established. The PDP must associate this context handle with the TCP connection between the two peers. 4.2.2.1 Sample Code gss_ctx_id_t context_hdl = GSS_C_NO_CONTEXT; do { - Receive the GSS_Nego message from the PEP - Retrieve the GSS token from the message input_token = /* token from the PEP */ maj_stat = gss_accept_sec_context ( &min_stat, &context_hdl, cred_hdl, input_token, input_bindings, &client_name, &mech_type, output_token, &ret_flags, &time_rec, &deleg_cred ); Gundavelli et al. [Page 11] INTERNET-DRAFT COPS Security Expires June 2000 if (output_token->length != 0) { - There is a token for the PEP - Create a Key Exchange Object using this token (output_token) as defined in Sec. 3.2 of this document. - Send GSS_Nego message with this Key Exchange Object to the PEP. }; if (maj_stat & GSS_S_COMPLETE) { - The PEP and the PDP have successfully established a GSS context break; } } while (maj_stat & GSS_S_CONTINUE_NEEDED); 4.3 Generating Signed Messages GSS_Get_Mic API must be used for generating the per-message signed token. The GSS context handle obtained in the process of GSS context establishment must be passed to this API. This API will provide support for data origin authentication and data integrity services. The entire COPS message starting with the COPS protocol header up to to the Sequence Number field of the Message Integrity Object and not including the GSS Signed Message field, has to be passed to the GSS_Get_Mic API for obtaining the per-message token. If the return value from this function is GSS_S_COMPLETE, indicates that an integrity check, suitable for the established security context is successfully generated. The generated per-message token has to be encapsulated in the Message Integrity Object with GSS-Signed sub-type as defined in Section 3.2 of this draft. This Integrity object must be the last object in the COPS message. Now, the entire COPS message including the Message Integrity object can be transmitted to its peer. For any other return values from this function, either the security context has to be re-negotiated with its peer as defined in section 4.2 of this draft or it needs to be handled based on the error code. Gundavelli et al. [Page 12] INTERNET-DRAFT COPS Security Expires June 2000 4.4 Validating Signed Message GSS_Verify_Mic is the inverse function of GSS_Get_Mic. The per-message token generated by GSS_Get_Mic API can be verified by the GSS_Verify_Mic API. The GSS context handle obtained in the process of GSS context establishment must be passed to this API. The GSS_Verify_Mic API can provide services such as data integrity, data origination and optional per-message replay detection of the message. On receiving the COPS message, the per-message token and the message starting with the COPS header up to the Sequence Number of the Message Integrity Object and not including the GSS Signed Message field are extracted from the message. If the C-Type of the Message Integrity Object in the received message is of type GSS-Signed, then the message with out the per-message token and the per-message token are passed to the GSS_Verify_Mic API as parameters. If the return value from this function is GSS_S_COMPLETE, indicates that a cryptographic MIC, contained in the passed per-message token fits the supplied message. For any other return values from this function, either the security context has to be re-negotiated with its peer as defined in section 4.2 of this draft or it needs to be handled based on the error code. 4.5 Deleting Security Context Termination process of the security context is the same for both the PEP or the PDP. Either one of them can close the security context at any time and must notify its peer. The PEP or the PDP can delete the established security context by simply calling the GSS_Delete_sec_context API and by passing the GSS context handle as a parameter to the API. The end desiring to close the security context also has notify its peer of this action by sending the GSS-Req message with the appropriate GSS-Operation Code in the message. The PEP or the PDP on receiving this message also has to call the GSS_Delete_sec_context API to flush the context level information by passing the associated GSS context handle. If multiple security contexts exist between the PEP and the PDP, each of these security contexts are unique and have to be deleted separately. 5. Security Considerations The security mechanism defined in this document is based on GSS-API and it relies on the strength of the chosen underlying authentication technology. Gundavelli et al. [Page 13] INTERNET-DRAFT COPS Security Expires June 2000 6. References [RFC 2078] Linn, J., "Generic Security Service Application Program Interface", Version 2, January 1997. [RFC 1510] Kohl, J., "The Kerberos Network Authentication Service (V5)", September 1993. [RFC 2222] Meyers, J., "Simple Authentication and Security Layer (SASL)" October 1997. [] Boyle, J., Cohen, R., Durham D., Herzog, S., Rajan, R., and Sastry, A., "The COPS (Common Open Policy Service) Protocol", November 1999 [] Wray, J., "Generic Security Service API Version 2: C - bindings", February 1999. [] Kwan, S., Garg, P., Gilroy, J., "GSS Algorithm for TSIG", June 1999. 7. Acknowledgments The Authors of this document would like to thank the following people: Hom Bahmanyar and Steve Bostock for their comments on this draft. 8. Author's Address Sri Gundavelli Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 527 6109 Email: sgundave@cisco.com Siva Vaddepuri Novell 2211 North First Street San Jose, CA 95131 USA Phone: +1 408 967 7821 Email: svaddepu@novell.com Gundavelli et al. [Page 14] INTERNET-DRAFT COPS Security Expires June 2000 Dave McNamee Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 525 1826 Email: dmcnamee@cisco.com Jonathan Trostle Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 527 6201 Email: jtrostle@cisco.com Gundavelli et al. [Page 15]