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:
<GSS-Nego> ::= <Common Header>
<GSS-API Token>
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> ::= <Common Header>
<Security Control Message Object>
[<Error Object>]
<Message Integrity Object>
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.
[<draft-ietf-rap-cops-08.txt>]
Boyle, J., Cohen, R., Durham D., Herzog, S., Rajan, R., and
Sastry, A., "The COPS (Common Open Policy Service) Protocol",
November 1999
[<draft-ietf-cat-gssv2-cbind-09.txt>]
Wray, J., "Generic Security Service API Version 2: C - bindings",
February 1999.
[<draft-skwan-gss-tsig-04.txt>]
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]