Network Working Group Kaushik Narayan Category :Experimental HCL-Cisco Title : draft-kaushik-radius-sec-ext-04.txt August 2000 Radius Security Extensions using Kerberos v5 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 February 22, 2001. Please send comments to the author (kaushik@cisco.com). Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a Authentication and Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC2865 and RFC2866. Kaushik expires February 2001 [Page 1] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 Table of Contents 1.0 Introduction ................................................. 2 2.0 Need for Radius encryption and role of Kerberos .............. 2 3.0 Kerberized Radius Operation .................................. 3 3.1 Encryption Operation ......................................... 5 3.2 Kerberized Radius Proxy Operation ............................ 6 3.3 End to End Security for Radius Cross Realm Operation ......... 6 3.4 Hop by Hop Security for Radius Cross Realm Operation ......... 7 3.5 Hop by Hop Extensions to the End-to-End security mode ........ 8 3.6 Request routing ............................................. 10 4.0 Packet Format ............................................... 11 5.0 Packet Types ................................................ 11 6.0 Attributes .................................................. 12 6.1 Kerberos-Data ............................................... 12 6.2 Kerberos-Mode ............................................... 13 6.3 Kerberos-Crypt .............................................. 14 7.0 Implementation using GSSAPI v2 .............................. 15 8.0 IANA Considerations ......................................... 16 9.0 Security Considerations ..................................... 16 10.0 References ................................................ 16 11.0 Author's Addresses.......................................... 17 12.0 Full Copyright Statement ................................... 17 1.0 Introduction This memo describes the changes required to the Remote Authentication Dial In User Service(RADIUS) protocol to integrate it with the Kerberos Network Authentication service (V5). The memo is an extension to the basic Radius protocol and the approach has been to avoid making any major changes to the Radius protocol. It also provides full backward compatibility with the current Radius protocol. This memo describes the use of Kerberos authentication and encryption mechanism in the Radius protocol using the additional Kerberos-Data, Kerberos-Mode and Kerberos-Crypt attributes. 2.0 Need for Radius encryption and role of Kerberos V The Remote Authentication Dial In User Service (RADIUS) provides basic Authentication, Authorization and Accounting (AAA) services to a Network Access Server (NAS). The NAS uses RADIUS to communicate with a RADIUS server which holds the AAA user/policy information. RADIUS is a UDP based protocol with a very elementary security framework which includes a 128 bit authenticator in the RADIUS header and static encryption of the password field. This level of security is insufficient for many applications. With the exception of some encrypted attributes, the RADIUS packet is transmitted in cleartext and thus is vulnerable to snooping. In addition, RADIUS password encryption uses a pre-configured key which is vulnerable to attack by snooping. The Kerberized RADIUS extensions can be used to provide end-to-end as well as hop-by-hop security for RADIUS proxy-based roaming or shared use networks. Kaushik expires February 2001 [Page 2] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 Kerberos V provides a authentication, integrity protection and encryption services which can be easily integrated seamlessly with other protocols. This document describes how RADIUS may be secured using Kerberos V. Note: RADIUS as defined in RFC2865 is referred to as Normal RADIUS operation in this document. The attributes defined in RFC2865 can be encrypted, with the exception of the Kerberos-Data, Kerberos-Mode, User-Name and Called-Station-Id attributes. The User-Name and Called-Station-Id attributes are used by RADIUS proxies to forward RADIUS packets, and thus need to be present in cleartext. RADIUS attributes, with the exception of Kerberos-Data, Kerberos-Mode, Kerberos-Crypt, User-Name and Called-Station-Id, are referred to as "normal" attributes in this document. 3.0 Kerberized RADIUS operation RADIUS clients and servers supporting the Kerberos Extensions use the existing RADIUS message types, as defined in RFC2865. The major change in operation is the addition of Kerberos-Data, Kerberos-Mode and Kerberos-Crypt attributes. In this section we examine the operation of Kerberized RADIUS clients and servers, which use "radius" as the keyword in the Kerberos service principal. Thus, the Kerberos V principal for a RADIUS server called servername would be "radius/servername.localrealm@localrealm. The NAS uses the kerberos service principal to discover the capability of a Radius server to support Kerberos. Since the kerberos service principal is defined per Radius server or proxy only Kerberized Radius servers or proxies would have the service principals registered with the KDC. The KRB_TGS_REQ would fail trying to obtain a ticket for a non Kerberized Radius server or proxy and the NAS would revert back to using the "normal" Radius operation as defined in RFC 2865. Prior to contacting the RADIUS server, the RADIUS client will send a KRB_TGS_REQ to the Ticket Granting Service (TGS) in order to obtain credentials for the RADIUS server. The TGS will reply with a KRB_TGS_REP, containing a session key and Kerberos ticket to the RADIUS service. Where the credentials are cached on the RADIUS client, the KRB_TGS_REQ will not be sent, but the credentials are retrieved from the cache. A valid Ticket Granting Ticket(TGT) must be cached on the NAS prior to sending a request to the Ticket Granting Service(TGS). Kaushik expires February 2001 [Page 3] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 Once the RADIUS client has obtained a ticket to the RADIUS server, it will then create a KRB_AP_REQ message using the obtained credentials. The KRB_AP_REQ will have MUTUAL-REQUIRED and USE_SECRET_KEY set in the ap-options field in order to turn on mutual authentication mode and specify to the server to use its secret key to decrypt the Kerberos ticket. If encryption is desired, the RADIUS client encrypts the "normal" RADIUS attributes (all attributes with the exception of Kerberos-Mode, Kerberos-Data, User-Name and Called-Station-ID) using the session key. Since encryption is optional, the RADIUS client may decide to use Kerberos only for authentication. The Kerberos-Mode attribute indicates which security services are used. The encrypted attributes would be carried in the Kerberos-Crypt attribute, a detailed description of the encryption operation is given in the Section 3.1. The RADIUS client includes the KRB_AP_REQ message within the Kerberos-Data attribute and then sends the Access-Request or Accounting-Request packet to the RADIUS server. On reception of the Access-Request or Accounting-Request, the Kerberized RADIUS server obtains the secret key for the service principal from the Kerberos service. The server then parses the Kerberos-Data attribute to obtain the KRB_AP_REQ message. It then decrypts the enclosed Kerberos ticket using its secret key and extracts and verifies the Kerberos authenticator. In case of an error in Kerberos authentication, an Access-Reject is sent with a Kerberos-Data attribute including a KRB_ERROR message. If the Kerberos authentication succeeds, the Kerberos-Mode attribute is retrieved in order to determine whether the "normal" RADIUS attributes are encrypted. If so, the attributes are decrypted using the session key. The packet is then processed normally. In responding to the Access-Request or Accounting-Request, the RADIUS server forms a KRB_AP_REP message containing the Kerberos Response Authenticator. The KRB_AP_REP message is included within the Kerberos-Data attribute. The Kerberos-Mode attribute will be set to indicate the desired security services, and if encryption is desired then the "normal" attributes are encrypted using the session key. If no "normal" RADIUS attributes are returned in the reply (as would be the case for an Access-Reject), then the Kerberos-Mode attribute is not included. Kaushik expires February 2001 [Page 4] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 On receiving an Access-Accept, Access-Reject, Access-Challenge or Accounting-Reply from the RADIUS server, the NAS retrieves the Kerberos-Data attribute. If the Kerberos-Data attribute contains a KRB_AP_REP mesasge, the NAS decrypts the message and authenticates the server. If the authentication fails, then the NAS silently discards the packet. Only Access-Reject packets should contain a KRB_ERROR message; if a KRB_ERROR message is included in another packet then the NAS will silently discard it. Once the message is authenticated, the NAS retrieves the "normal" RADIUS attributes (if any) and decrypts them if confidentiality is indicated in the Kerberos-Mode attribute. At this point, the NAS and RADIUS server have mutually authenticated, and so the NAS destroys the current Kerberos context and creates a new Kerberos context for future interactions with the RADIUS server. Thus a new Kerberos context is created for every RADIUS request and reply. 3.1 Encryption Operation The Attribute-Type-Value 3 tuples for all "normal" attributes would be encrypted as a single block using the ciphersuite negotiated within Kerberos V. As defined in RFC 1510, the following ASN.1 definition describes the encrypted contents of the value field: EncryptedData ::= SEQUENCE { etype[0] INTEGER, -- EncryptionType kvno[1] INTEGER OPTIONAL, cipher[2] OCTET STRING -- ciphertext } CipherText ::= ENCRYPTED SEQUENCE { confounder[0] UNTAGGED OCTET STRING(conf_length) OPTIONAL, check[1] UNTAGGED OCTET STRING(checksum_length) OPTIONAL, msg-seq[2] MsgSequence, pad UNTAGGED OCTET STRING(pad_length) OPTIONAL } The ciphertext would carried in the Kerberos-Crypt attribute. Details of the Kerberos-Crypt attribute can be found in Section 6.3. Kaushik expires February 2001 [Page 5] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 3.2 Kerberized Radius Proxy Operation Kerberized RADIUS proxies may operate in either End-to-End or Hop-by-Hop mode. End-to-End mode is used where the sender desires end-to-end confidentiality, authentication and integrity protection. For example, End-to-End mode may be used in order to prevent a proxy from gaining access to a PAP or tunnel password. The sender uses the Kerberos-Mode attribute to indicate which of the modes is desired for a particular packet. The Kerberos-Mode attribute is described in Section 6.2. 3.3 End to End Security Radius Cross Realm Operation This mode provides end-to-end confidentiality, authentication or integrity protection between the NAS and home RADIUS server. Encryption is mandatory in End-to-End mode. In routing the Access-Request to the home RADIUS server, the NAI is typically used, as described in RFC 2486. Based on the NAI, the NAS can determine whether the Access-Request will be served locally, or whether it needs to be proxied. In the case of a proxied request, the IP address and port of the destination RADIUS server can be determined as described in the next section. The NAS can then create the Kerberos V service principal, which is of the form: radius/servername.homerealm@homerealm, where "homerealm" represents the realm portion of the NAI, described in RFC 2486. The NAS then sends a KRB_TGS_REQ to the home realm Ticket Granting Service to obtain a cross realm ticket for the home RADIUS server. The home realm Kerberos Key Distribution Centre (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 February 2001 [Page 6] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 The NAS then uses the Kerberized Radius operation described previously to create the Access-Request or Accounting-Request along with the Kerberos-Data, Kerberos-Mode and Kerberos-Crypt attributes. For use in End-to-End mode, the Kerberos-Mode attribute is set to 11. In End-to-End mode the User-Name and Called-Station-Id attributes are not encrypted since RADIUS proxies typically use these attributes in forwarding. In cross-realm operation, the RADIUS proxy uses the NAI as determined from the User-Name or Called-Station-ID attributes to locate the home RADIUS server as described below. The proxy checks the Kerberos-Mode which in this case would indicate an end-to-end operation, and then creates a new Access-Request or Accounting-Request and sends it to the home RADIUS server. In doing this, the RADIUS proxy copies the Kerberos-Data, Kerberos-Mode and Kerberos-Crypt attribute to the new packet along with the other RADIUS attributes. Thus, RADIUS proxy operation is transparent with respect to the Kerberized RADIUS extensions, and home RADIUS server operation is not altered from the Kerberized RADIUS server operation described above. Note: Kerberized Radius proxies can also initiate an end-to-end security mode. This would ensure that the security services are available even while working with a legacy NAS which does not support Kerberos. In such a case the Kerberized Radius proxy would receive a normal Radius request and the proxy would create an end-to-end security context with the homeserver. The Kerberized Radius proxy needs to be preconfigured to create end-to-end security contexts with a homeserver while working with a legacy NAS. 3.4 Hop by Hop Security for Radius Cross Realm Operation In Hop-by-Hop mode, a Kerberos security context is created between the RADIUS client and server. Hop-by-Hop mode may be used to support only authentication and integrity protection (Kerberos-Mode = 20), or in addition, confidentiality may be supported (Kerberos-Mode = 21). Whereas encryption is mandatory in Hop-by-Hop mode for cross-realm hops, it is optional for local realm hops. In Hop-by-Hop mode, the NAS first obtains a ticket for the service principal from the local realm KDC. The Kerberos service principal for this operation would be of the form radius/servername.localrealm@localrealm. The NAS then uses the Kerberized Radius operation described above to create the Access-Request or Accounting-Request along with the Kerberos-Data attribute which contains the KRB_AP_REQ message. The Kerberos-Mode attribute is set to 20 or 21 depending on whether confidentiality services are desired. Kaushik expires February 2001 [Page 7] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 In cross-realm operation, the RADIUS proxy uses the NAI as determined from the User-Name or Called-Station-ID attributes to locate the home RADIUS server as described below. The proxy then checks the Kerberos-Mode attribute. Where Hop-by-Hop mode is indicated, the proxy authenticates the packet as described above, and then decrypts the encrypted "normal" RADIUS attributes where encrypted Hop-by-Hop mode is indicated (Kerberos-Mode = 21). The proxy then obtains a cross realm ticket for the service principal from the home realm KDC. The home realm Kerberos Key Distribution Centre (KDC) can be either be statically configured or can be discovered dynamically. The Kerberos V service principal is of the form radius/servername.homerealm@homerealm. The RADIUS proxy then creates a new Access-Request or Accounting-Request with the "normal" Radius attributes encrypted and with the Kerberos-Data attribute containing the cross realm KRB_AP_REQ, the Kerberos-Crypt containing the encrypted attributes and Kerberos-Mode set to 21(cross realm). 3.5 Hop by Hop Extensions to the End-to-End security mode This mode is an extension of the End-to-End security mode with support for hop-by-hop operation. In the end-to-end operation a Kerberos security context is established between the NAS and the Radius homeserver and the intermediate transparently forward the Kerberized Radius request. This mode provides a mechanism for additional security contexts to be created between the intermediate Radius proxies and the Radius homeserver. These additional security contexts allow intermdiate proxies to authenticate themselves to the Radius homeserver. The Kerberos-Mode attribute for this mode is 31. In this mode, the NAS would use the end-to-end operation described above to obtain a cross realm ticket for the homeserver and create a Radius Access-Request with the Kerberos-Data containing the KRB_AP_REQ. An intermediate Radius proxy on reception of this Access-Request can transparently forward the Kerberized Radius Request based on the User-Name or Called-Station-Id similar to normal end-to-end operation. Optionally the Radius proxy can choose to obtain a ticket for the Radius homeserver and add the KRB_AP_REQ message received to the Kerberos-Data attribute present in the Access-Request. In this mode the Kerberos-Data attribute would almost be similar the Proxy-State attribute and intermediate proxies can choose just to piggy back thier KRB_AP_REQ message along with the KRB_AP_REQ message sent by the NAS. The order should be maintained from left to right and intermediate proxies should not tamper the order. The KRB_AP_REP responses would be in the same order as the KRB_AP_REQ messages all intermediate proxies need not add a KRB_AP_REQ message. Morever a proxy shouldnot add a KRB_AP_REQ message if the length of packet along with it's KRB_AP_REQ message exceeds maximum length of a Radius packet (i.e. 4096 bytes). Kaushik expires February 2001 [Page 8] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 A KRB_AP_REQ or KRB_AP_REP message would typically be carried in multiple Kerberos-Data attributes. Since in this mode there would more than one KRB_AP_REQ or KRB_AP_REP messages as part of the Radius request or response, there is a need to delimit each KRB_AP_REQ or KRB_AP_REP message. This can be achieved by accomodating the length of the KRB_AP_REQ or KRB_AP_REP message in the Value field of the Kerberos-Data attribute. This modified Kerberos-Data attribute would contain the complete length of the KRB_AP_REQ message in the first two bytes of the Value field. The first Kerberos-Data attribute containing that KRB_AP_REQ or KRB_AP_REP message would be a modified Kerberos-Data attribute and there would one modified Kerberos-Data attribute per KRB_AP_REQ or KRB_AP_REP message in the Radius Request or Response. A summary of the format of the modified Kerberos-Data attribute is given below. 0 1 2 3 4 0 8 8 8 8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Message Length | KRP_AP_REQ/KRB_AP_REQ ..... ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- The NAS would insert the length of the KRB_AP_REQ message in the first two bytes of the Value field of the Kerberos-Data. The remaining 251 octets would contain the KRB_AP_REQ message. It is conceivable that the KRB_AP_REQ message will not fit within the 251 octets, in which case the KRB_AP_REQ message would be split up and carried in multiple instances of the Kerberos-Data attributes. The Value field of only the first Kerberos-Data attribute would contain the length of KRB_AP_REQ message and the remaining Kerberos-Data attributes (if any) would not carry the length of the KRB_AP_REQ message. Any intermediate proxy can also decide to piggyback a KRB_AP_REQ message provided the length of the Radius Request doesnot exceed 4096 bytes (maximum length of the Radius packet). In case an intermediate proxy decides to piggyback a KRB_AP_REQ it would use the same procedure as described in the previous section to add additional Kerberos-Data attributes to the Radius request. The Radius homeserver would simply concatenate all the Kerberos-Data attributes in the Radius Request and extract all the KRB_AP_REQ messages using the length of each of the KRB_AP_REQ messages present at the start of each KRB_AP_REQ message. The Radius homeserver would authenticate each of the KRB_AP_REQ messages received and a KRB_AP_REP or KRB_ERROR message would be generated. The KRB_AP_REP or KRB_ERROR message would be sent in the same order as the KRB_AP_REQ messages received in the Radius Request. Kaushik expires February 2001 [Page 9] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 Any intermediate proxy which had added a KRB_AP_REQ to the Radius Request would extract the KRB_AP_REP or KRB_ERROR from the Radius Response. If the Response contains a KRB_AP_REP message then the intermediate server would authenticate the KRB_AP_REP message and forward the Radius response if the authentication succeeds. Alternatively if the authentication fails or the Radius Response contains a KRB_ERROR message the intermediate proxy would not forward the Radius Response and just drop it. Encryption is mandatory for this mode since the Radius Request and Response cross the local realm. 3.6 Request routing As described in RFC 2486, the Network Access Identifier (NAI) is of the form user@realm. This section describes how the NAI, which is typically contained within the RADIUS User-Name or Called-Station-ID attributes, may be used to route RADIUS requests. The procedure is similar to that used for routing of SIP requests, as described in RFC 2543. When a RADIUS client wishes to send a request, the client MAY send it to locally configured RADIUS proxy server, independent of the NAI. The RADIUS proxy server MAY then forward the request based on local configuration, or it MAY forward the request by determining the IP address and port of the destination RADIUS server, based on the realm portion of the NAI. Alternatively, the RADIUS client MAY send the request directly to the destination RADIUS server. The IP address and port of the destination RADIUS server MAY be determined based on local configuration or it MAY be determined by querying DNS, using either an address record approach, or an SRV record approach. The address record approach is the recommended default behavior, since SRV records, described in RFC 2782, are not yet widely deployed. Thus, the destination realm cannot generally be depended upon to provide an SRV record for the RADIUS server. In the address record approach, the client or proxy queries the DNS server for address records (A RRs, AAAA RRs, or other similar address records) within the NAI realm. Note that since there are no mandatory rules for naming of RADIUS servers, the address record approach may not succeed even if a RADIUS server exists within the destination realm. For example, the RADIUS server could be named radius.realm (recommended), or it could have some other arbitrary name. Kaushik expires February 2001 [Page 10] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 Where the DNS server returns no address records, the client or proxy SHOULD utilize the SRV record approach. However if one or more addresses are located but no RADIUS server is found at any of those addresses, then the client or proxy should conclude that the RADIUS server is down, rather than utilizing the SRV approach. The approach for obtaining the IP address and port of the RADIUS server via SRV records is similar to that described in Appendix D of RFC 2543. The protocol to use when querying for the SRV record is "radius"; the transport is UDP. Since SRV records contain port numbers in addition to IP addresses, the client or proxy always uses the port number when contacting the RADIUS server. If there is no port number available, then the RADIUS default ports are used, as specified in RFCs 2865 and RFC 2866. The results of the SRV query are ordered based on priority. If the DNS does not return any SRV records, then the client or proxy concludes that the search has failed. Otherwise, the client or proxy contacts each server in the order listed. If no server can be contacted, the client or proxy gives up. A client or proxy MAY cache a successful DNS query result. A successful query is one where the server is determined to be available at one of the addresses returned in the answer. When the client or proxy wishes to send a request to the same host, it MUST start the search as if it had just received this answer from the name server. The client MUST follow the procedures in RFC 1035 and 2308 regarding DNS cache invalidation when the DNS time-to-live expires. A client SHOULD be able to interpret explicit network notifications (such as ICMP messages) which indicate that a server is not reachable, rather than relying solely on timeouts. 4.0 Packet Format The Packet Format is the same as defined in RFC2865 and RFC2866. 5.0 Packet Types The Packet Types are exactly the same as defined in RFC2865 and RFC2866. Kaushik expires February 2001 [Page 11] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 6.0 Attributes The Kerberos-Data, Kerberos-Mode and Kerberos-Crypt attributes are used in order to support the Kerberized RADIUS extensions. RADIUS Attribute values are specified in the most recent "Assigned Numbers" RFC [5]. Values 192-223 are reserved for experimental use, 224-240 Aare reserved for implementation specific use, and 241-255 are reserved and should not be used. This document uses the following values: 92 Kerberos-Data 93 Kerberos-Mode 94 Kerberos-Crypt 6.1 Kerberos-Data Description The Kerberos-Data attribute contains the KRB_AP_REQ request which is sent from the RADIUS client to the RADIUS server, as well as the KRB_AP_REP or KRB_ERROR response which is sent from the RADIUS server to client. If the KRB_AP_REQ, KRB_AP_REP or KRB_ERROR messages exceed 253 octets then the message are split up into 253 octet blocks. Each 253 octet block is then carried in a Kerberos-Data attribute and multiple Kerberos-Data attributes are present in the RADIUS packet. When included in an Access-Request or Accounting-Request, the Kerberos-Data attribute contains the Kerberos authenticator authenticating the RADIUS client, as well as the session key used for encrypting the "normal" RADIUS attributes. When included in an Access-Response or Accounting-Response, the Kerberos-Data attribute contains the Kerberos authenticator of the RADIUS server or proxy, which is used for mutual authentication. RFC1510 describes the fields and authentication checks made on the Kerberos Request and Response authenticator. A summary of the Kerberos-Data Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 92 for Kerberos-Data. Length Length of the KRB_AP_REQ or KRB_AP_REQ message. Kaushik expires February 2001 [Page 12] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 String KRB_AP_REQ or KRB_AP_REQ message. The Value field is modified to support the Hop-by-Hop extensions for the End-to-End mode. The details of the modification have already been discussed in Section 3.5. 6.2 Kerberos-Mode Description The Kerberos-Mode attribute is used to indicate the mode of Kerberized Radius operation. This attribute is a two digit number with the lower digit indicating whether the "normal" RADIUS attributes have been encrypted with the Kerberos session key. The upper digit indicates whether Hop-by-Hop or End-to-End mode is being used. The modes of operation are: 1> Normal Mode 2> End to End Proxy Mode 3> Hop by Hop Proxy Mode 4> Hop-by-Hop extensions for End-to-End Proxy Mode Note: The Kerberos-Data and Kerberos-Mode attributes are not encrypted and these attributes are sent in clear text. The Kerberos-Mode attribute is applicable to the "normal" Radius attributes only. A summary of the Kerberos-Mode Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 93 for Kerberos-Mode. Length 6 Value 00 - Normal Mode with Cleartext Radius attributes 01 - Normal Mode with Encrypted Radius attributes 11 - End to End Proxy Mode 20 - Hop by Hop Proxy Mode with Cleartext Radius attributes 21 - Hop by Hop Proxy Mode with Encrypted Radius attributes 31 - Hop by Hop Extensions for End-to-End security mode Kaushik expires February 2001 [Page 13] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 6.3 Kerberos-Crypt Description The Kerberos-Crypt attribute would carry the encrypted Attribute-Length-Value 3-tuples for all the "normal" attributes. This attribute would be present only for the Kerberos modes which require encryption of the "normal" attributes. First the Attribute-Type-Value 3 tuple would be created for all attributes as defined in the Radius operation in RFC2865. Subsequently the block of data containing the Attribute-Length-Value of the "normal" attributes (all attributes with the exception of Kerberos-Mode, Kerberos-Data, User-Name and Called-Station-ID) would be encrypted using the encryption operation described in section 3.1. The ciphertext generated would be carried in the Value field of the Kerberos-Crypt attribute. It is conceivable that the ciphertext generated will not fit within the 253 octet maximum allowable in a single RADIUS attribute and the ciphertext should be split among multiple instances of the Kerberos-Crypt attributes. A summary of the Kerberos-Crypt Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 94 for Kerberos-Crypt. Length Length of the ciphertext String Ciphertext block generated by encryption of the "normal" Radius attributes. Kaushik expires February 2001 [Page 14] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 7.0 Implementation using GSSAPI v2 This section we examine how the Kerberized RADIUS extensions can be implemented on the client and server using the Generic Security Service Application Program Interface, Version 2 (RFC2078) for Kerberos. This section examines Normal Mode RADIUS operation. The RADIUS client initially calls GSS_Init_sec_context to initialize the Kerberos session context. It then checks the local cache for an existing ticket for the radius service principal. If it is not found then the RADIUS client requests credentials from the Ticket Granting Service (TGS). The credentials obtained are then used to construct a KRB_AP_REQ. The Kerberized RADIUS client should call the GSS_Init_sec_context with the mutual_req_flaq (mutual-authentication) and sequence_req_flag set to TRUE and mech_type set to NULL to indicate the default Mechanism type. The GSS_Init_sec_context returns the KRB_AP_REQ message in an output token and returns major_status as GSS_S_CONTINUE_NEEDED in case the call does not encounter errors. The RADIUS client can use the GSS_Wrap method to encrypt the "normal" RADIUS attributes with the Kerberos session key. If GSS_Init_sec_context returns an error, then the RADIUS client will log the error. Note: The GSSAPI v2 implementation should support Per-Message Protection During Context Establishment. The GSS_Init_sec_context call would return prot_ready_state set to TRUE in case the GSSAPI v2 implementation supports this feature. This would allow the use of GSS_Wrap to encrypt the "normal" RADIUS attributes even before receiving a GSS_S_COMPLETE status from GSS_Init_sec_context call. In case this feature is not supported by the Kerberos GSSAPI v2 implementation then authentication without encryption can be used. On reception of a Kerberized RADIUS request, the RADIUS server calls GSS_Acquire_Cred to acquire the secret key for the RADIUS server principal. It then calls GSS_Accept_sec_context and passes it the token received in the Kerberos-Data attribute as an input token parameter and the secret key obtained in the acceptor_cred_handle input parameter. GSS_Accept_sec_context authenticates the Kerberized RADIUS client and extracts the Kerberos session key. It returns the KRB_AP_REP message in the output_token and status set to GSS_S_COMPLETE on successful completion. Any other return code indicates an error, in which case the server sends an Access-Reject with Kerberos-Data attribute set to the KRB_ERROR message input_token. The RADIUS server checks the Kerberos-Mode attribute, and if encryption is indicated, GSS_Unwrap is used to decrypt the "normal" RADIUS attributes. After this, normal RADIUS processing occurs and a RADIUS reply is generated. If "normal" RADIUS attributes included in the RADIUS response are encrypted using GSS_Wrap, the Kerberos-Mode attribute is set accordingly. The server also includes the Kerberos Response authenticator in the Kerberos-Data attribute. Kaushik expires February 2001 [Page 15] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 The RADIUS client then receives the response from the server and passes the context token received in the Kerberos-Data attribute to the GSS_Init_sec_context method. The GSS_Init_sec_context method checks the data included in the token and returns an error in case of a KRB_ERROR message in the token. If the context token contains a KRB_AP_REP then the GSS_Init_sec_context would process the token in order for the RADIUS client to authenticate the server and returns the GSS_S_COMPLETE status to indicate that mutual authentication is successful. After this, the RADIUS reply is processed. In case the GSS_Init_sec_context method returns an error during authentication of the context token, the Kerberized RADIUS operation fails and an error is logged. This document only discusses the major GSSAPI v2 interfaces used to implement the Kerberized RADIUS extensions. The other helper interfaces that would also be used are not discussed; more details of all the GSSAPI v2 interfaces can be found in RFC2078. 8.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 RADIUS name spaces. 9.0 Security Considerations This entire document deals with security considerations related to the RADIUS protocol. 10.0 Acknowledgments I would like to thank Bernard Aboba of Microsoft whose suggestions and comments have been invaluable. I would also like to thank Chandrasekhar S. of HCL-Cisco for assisting me in implementing the prototype for this draft. 11.0 References [RFC-1510]: Kohl, J., and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC-2865]: C. Rigney, A. Rubens, W. Simpson, and S. Willens "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC-2486]: Aboba, B., Beadles, M., "The Network Access Identifier", RFC 2486, January 1999. [RFC-2782]: A. Gulbrandsen, P. Vixie, L. Esibov "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, Feb 2000 [RFC-2866]: C. Rigney "RADIUS Accounting", RFC 2866, June 2000. [RFC-1964]: Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, January 1997 Kaushik expires February 2001 [Page 16] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 [RFC-2078]: Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997 [RFC-1509]: Wray, J., "Generic Security Service Application Program Interface: C-bindings", RFC 1509, September 1993. [RFC-2194]: B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang "Review of Roaming Implementations", RFC 2194, September 1997. [RFC-2308]: Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998. 11.0 Author's Address Kaushik Narayan HCL-Cisco Offshore Development Centre, 49-50, Nelson Manickam Road, Chennai, Tamilnadu 600 029 India EMail: kaushik@cisco.com Phone: +091-44-3741939 12.0 Full Copyright Statement Copyright (C) The Internet Society (2000). 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 February 2001 [Page 17]