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 <draft-
kaushik-radius-sec-ext-04.txt>, 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]