Network Working Group Kaushik Narayan
Category :EXPERIMENTAL HCL-CISCO, Chennai
Title : draft-kaushik-radius-sec-ext-01.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 <draft-
kaushik-radius-sec-ext-01.txt>, 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]