Network Working Group Kaushik Narayan Category :EXPERIMENTAL HCL Technologies Ltd. Title : draft-kaushik-radius-sec-ext-00.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 December 22, 2000. 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 RFC2138 and RFC2139. Kaushik expires December 2000 [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 4.0 Packet Format ................................................ 4 5.0 Packet Types ................................................. 5 6.0 Attributes ................................................... 5 6.1 Kerberos-Data ................................................ 5 6.2 Kerberos-Crypt ............................................... 6 7.0 Implementation using GSSAPI v2 ............................... 7 8.0 IANA Considerations .......................................... 8 9.0 Security Considerations ...................................... 8 10.0 References ................................................. 9 11.0 Author's Address ............................................ 9 12.0 Full Copyright Statement .................................... 9 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 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 and Kerberos-Crypt attributes. 2.0 Need for Radius encryption and role of Kerberos V5 Remote Authentication Dial In User Service (RADIUS) provides basic Authentication, Authorization and Accounting(AAA) services to a Network Access Server(NAS). The NAS uses the Radius protocol to communicate with a Radius server which has the AAA user/policy information. Radius is a UDP based protocol with a very elementary security framework which includes a 128 bit authenticator and static encryption of the password field in the Radius header. This level of security just isn't enough and is major drawback with the current Radius protocol. Essentially there are a couple of problems, firstly since most of the Radius packet is transmitted in cleartext it is vulnerable to attack from a third party. Secondly the radius password encryption uses a static encryption mechanism using a preconfigured key which makes the password vulnerable to attack by packet interception. Kerberos V5 provides a network authentication and encryption service which can easily integrated seamlessly with other protocols. Radius already provides a basic framework for encryption, it's just a matter of extending the framework to fit Kerberos. Kaushik expires December 2000 [Page 2] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 Note: The original operation and attributes defined in the Radius protocol(RFC2138) are referred as normal Radius operation and normal Radius attributes in this memo. 3.0 Kerberized Radius operation The Kerberized Radius operation basically adds the Kerberos authentication process to the normal Radius operation. All the Radius packets types would be the same, just additionally they would carry the Kerberos-Data and Kerberos-Crypt attributes. Note: Currently there is no way a NAS cannot determine whether a Radius server is Kerberized or not. If a NAS sends a Kerberized Radius request to a Radius server which doesn't support Kerberos, the server would silently discard the Radius packet since Kerberos-Data and Kerberos-Crypt would be invalid Radius codes for the server. The NAS cannot determine whether the request has timed out because of a network error or because the server doesn't support Kerberos. Dynamic discovery of Radius servers supporting Kerberos is out of the scope of this memo. Implementation have to take care that clients are made aware whether Radius servers support Kerberos via some static configuration. This section we take a look at a typical operation and the interaction of the Kerberized Radius peers when the NAS receives a authentication request. This operation would remain the same for an accounting request as well. The "radius" keyword would be used in the Kerberos service principal. The Kerberos principal for a Radius server called servername would be radius/servername.anywhere.com@ANYWHERE.COM. The NAS would first send out a KRB_TGS_REQ to the Ticket Granting Service(TGS) to obtain the credentials for the Radius server. The TGS would reply back with a KRB_TGS_REP which would contain a session key and a Kerberos ticket. In case the credentials are cached on the NAS the KRB_TGS_REQ won't be sent but the credentials would be retrived from the cache. It is required that a valid Ticket Granting Ticket(TGT) has been cached on the NAS before sending a request to the Ticket Granting Service(TGS). The NAS would first create a KRB_AP_REQ message using the credentials just obtained. The KRB_AP_REQ message will have MUTUAL-REQUIRED and USE_SECRET_KEY set in its ap-options field to turn on the mutual authentication mode and specify to the server to use it's secret key to decrypt the Kerberos ticket. The NAS would first encrypt the normal Radius attributes for a Access Request using the session key. The encryption is an optional phase and the NAS can decide not encrypt the attributes in case it wants to use Kerberos only for authentication. The NAS needs to set the Kerberos-Crypt attribute to 1 or 0 based on whether it wants to use encryption or not. The NAS would set the Kerberos-Data attribute with the KRB_AP_REQ message and create the Access-Request packet which would be sent to the Radius Server. Kaushik expires December 2000 [Page 3] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 The Kerberized Radius server on reception of the Access-Request would get the secret key for the service principal from the Kerberos service tab file. The server would then get the Kerberos-Data attribute and retrieve the KRB_AP_REQ message, it would then decrypt the Kerberos Ticket using it's secret key and extract the Kerberos session key. This session key would be used to extract the Kerberos authenticator and authenticate the NAS. In case of an any error in the Kerberos authentication, an Access-Reject with Kerberos-Data attribute set with KRB_ERROR message would be sent back to the NAS. In case the Kerberos authentication succeeds the Kerberos-Crypt attribute is retrieved to check whether the normal Radius attributes are encrypted and these attributes are retrived and decrypted using the session key in case the Kerberos-Crypt is set to 1. The Radius protocol would then resort to it's normal processing to authenticate the User-Name, User-Password from it's database of users. The Radius server based on the Radius processing can respond with Access-Accept, Accept-Reject or a Access-Challange. In any case the Radius server would form a KRB_AP_RES message which would contain the Kerberos Response Authenticator. The Kerberos-Data attribute would be set with the contents of the KRB_AP_RES message. The server can also set the value of the Kerberos-Crypt attribute in case it wants to encrypt any of the normal Radius attributes to be returned to the NAS and these attributes would be encrypted using the Kerberos session key. The Kerberos-Crypt attribute would not be set in case no normal Radius attributes have to returned in the reply. The Radius server response is ready and is sent back to the NAS. The NAS would receive the reply from the Radius server and retrieve the Kerberos-Data attribute, if this attribute contains a KRB_ERROR message it would indicate that the Radius server had encountered an error in the Kerberos authentication and the NAS would throw a Login error to the user. In case the Kerberos-Data attribute contains a KRB_AP_RES message, the NAS would decrypt the message and authenticate the server. In case this authentication fails the NAS would send a Login error to the user even if a Access-Accept or Access-Challange has been sent by the Radius Server. The NAS would then retrieve the normal Radius attributes (if any) and decrypt them if the Kerberos-Crypt attribute is set to 1. At this point the NAS and Radius server have mutually authenticated each other, the NAS would destroy the current Kerberos context and it would create a new Kerberos context for any further interaction with the Radius server. This means that there would a new Kerberos context created for every Radius request and reply. Kaushik expires December 2000 [Page 4] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 4.0 Packet Format The Packet Format is exactly the same as defined in RFC2138 and RFC2139. 5.0 Packet Types The Packet Types are exactly the same as defined in RFC2138 and RFC2139. 6.0 Attributes The format and types of Attributes are the same as defined in RFC2138 Additional Radius attributes Kerberos-Data and Kerberos-Crypt would be used to carry the Kerberos messages. The Radius Attribute Type values are specified in the most recent "Assigned Numbers" RFC [5]. Values 192-223 are reserved for experimental use, values 224-240 are reserved for implementation specific use, and values 241-255 are reserved and should not be used. This memo uses the following values: 92 Kerberos-Data 93 Kerberos-Crypt 6.1 Kerberos-Data Description The Kerberos-Data attribute would contain the KRB_AP_REQ request which would be sent from the NAS to server and KRB_AP_RES or KRB_ERROR response which would be sent back from the Radius server. In case the length KRB_AP_REQ,KRB_AP_RES or KRB_ERROR messages exceed 253 octets, then these messages have to be split up into 253 octet blocks. Each 253 octet block would be carried in a Kerberos-Data attribute and multiple instances of the Kerberos-Data attribute would be present in the Radius packet. The Request Kerberos-Data attribute contains the Kerberos authenticator for the NAS authentication and also the session key used for encrypting the normal Radius attribute values. The Response Kerberos-Data contains the Kerberos authenticator sent back by the Radius Server for mutual authentication. Refer to RFC1510 for fields and all the 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Kaushik expires December 2000 [Page 5] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 Type 92 for Kerberos-Data. Length Length of the KRB_AP_REQ or KRB_AP_REQ message . String KRB_AP_REQ or KRB_AP_REQ message. 6.2 Kerberos-Crypt Description The Kerberos-Crypt attribute is used to indicate that the current set of Radius attributes sent along with the Kerberized Radius PDUs have been encrypted with the Kerberos session key. Certain set of Kerberized Radius interactions would like to use the basic Kerberos authentication without actually encrypting the normal Radius attributes. In such cases this attribute can be set to 0 indicating that the normal Radius attributes in the Kerberized Radius PDU are in cleartext. Note: The Kerberos-Data and Kerberos-Crypt attributes are not encrypted and these attributes are sent in cleartext. The Kerberos-Crypt attribute is applicable to the normal Radius attributes only. 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 | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 93 for Kerberos-Crypt. Length 6 Value 1 - Encrypted Radius attributes 0 - Cleartext Radius attributes Kaushik expires December 2000 [Page 6] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 7.0 Implementation using GSSAPI v2 This section we take a look at 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. The NAS would first call GSS_Init_sec_context to initialize the Kerberos session context. It will check the local cache for an existing ticket for the radius service principal, if it is not found then it would request credentials from the Ticket Granting Service(TGS). The credentials obtained are then used to construct a KRB_AP_REQ. The Kerberized NAS should call the GSS_Init_sec_context with the mutual_req_flag (mutual-authentication) and sequence_req_flag set to TRUE and mech_type should be set to NULL to indicate default Mechanism type. The GSS_Init_sec_context would return the KRB_AP_REQ message in an output token and return major_status as GSS_S_CONTINUE_NEEDED in case the call doesn't encounter any errors. The NAS can use GSS_Wrap method to encrypt the normal Radius attributes with the Kerberos session key. In case the GSS_Init_sec_context returns an error, then the NAS returns an error to the user. 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 only the Kerberos authentication without any encryption can be used (Kerberos-Crypt = 0). The Radius server on reception of a Kerberized Radius request would first call GSS_Acquire_Cred to acquire the secret key for the Radius server principal. It would then call GSS_Accept_sec_context and pass it the token received in the Kerberos-Data attribute as input token parameter and the secret key obtained in the acceptor_cred_handle input parameter. The GSS_Accept_sec_context would authenticate the Kerberized NAS and extract the Kerberos session key. It would return the KRB_AP_RES message in the output_token and status set to GSS_S_COMPLETE on successful completion, any other return code would indicate an error and the server would send a Kerberos_Access_Reject with Kerberos-Data attribute set to KRB_ERROR message input_token. The Kerberos-Crypt attribute would be checked for encryption and in case it is true, the GSS_Unwrap is used to decrypt the normal Radius attributes After this the normal Radius operation takes over and a Radius reply is created. Any normal Radius attributes generated from the Radius response to be returned to the NAS can be encrypted using GSS_Wrap and the Kerberos-Crypt is set to 0 or 1 accordingly, the Kerberos-Data attribute is set with the Response Kerberos authenticator. Kaushik expires December 2000 [Page 7] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 The NAS would receive the reply from the server and pass the context token received in the Kerberos-Data attribute to the GSS_Init_sec_context method. The GSS_Init_sec_context method check the data included in the token and return an error in case of a KRB_ERROR message in the token. If the context token contains a KRB_AP_RES then the GSS_Init_sec_context would process the token in order to achieve mutual authentication from the NAS's viewpoint and returns the GSS_S_COMPLETE status to indicate that the mutual authentication is successful. After this the normal Radius operation takes over and processes the received Radius reply. 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 would be returned to the user. This memo just looks at the major GSSAPI v2 interfaces that would be used to implement the Radius extensions. The other helper interfaces that would also be used are not discussed in this memo, 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 References [RFC-1964]: Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, January 1997 [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-1510]: Kohl, J., and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC-2138]: C. Rigney, A. Rubens, W. Simpson, and S. Willens "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997. [RFC-2139]: C. Rigney "RADIUS Accounting", RFC 2139, April 1997. Kaushik expires December 2000 [Page 8] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 11.0 Author's Address Kaushik Narayan HCL Technologies Ltd. Cisco Offshore Development Centre, 49-50, Nelson Manickam Road, Chennai, Tamilnadu 600 029 India Phone: +091-44-3741939 EMail: kaushik@cisco.com 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 December 2000 [Page 9]