Network Working Group Kaushik Narayan Category :Experimental HCL-Cisco Title : draft-kaushik-radius-sec-ext-05.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 The RADIUS protocol described in RFC2865 and RFC2866 defines hop by hop message integrity and minimal AVP encryption using statically configured symmetric transforms to secure communication between two adjacent RADIUS peers. Cross domain Radius applications like roaming have a requirement for end to end security. This document specifies how end to end AVP authentication, integrity and encryption can be provided for RADIUS using the Kerberos protocol. This document also specifies how additionally stronger hop by hop AVP authentication, integrity and encryption can be provided for RADIUS using the Kerberos protocol. 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 End to End Security using Kerberized Radius .................. 4 3.2 Hop by Hop Security using Kerberized Radius .................. 7 3.3 Encryption operation ......................................... 7 3.4 Integrity protection operation ............................... 8 3.5 Request routing .............................................. 9 4.0 Packet Format ............................................... 11 5.0 Packet Types ................................................ 11 6.0 Attributes .................................................. 11 6.1 Kerberos-EndtoEnd ........................................... 11 6.1.1 Kerberos Authentication message ........................... 12 6.1.2 Privacy protection message ................................ 13 6.1.3 Integrity protection message .............................. 13 6.1.4 Integrity protected attribute list ........................ 14 6.2 Kerberos-HopbyHop ........................................... 15 7.0 Implementation Notes ........................................ 16 8.0 IANA Considerations ......................................... 17 9.0 Security Considerations ..................................... 17 10.0 References ................................................ 17 11.0 Author's Addresses.......................................... 17 12.0 Full Copyright Statement ................................... 18 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 it provides full backward compatibility with the current Radius protocol. This memo describes the use of Kerberos authentication and encryption mechanism in the Radius protocol to provide End to End security and additional Hop by Hop security for Radius . The draft employs two additional Radius attributes namely Kerberos-End-to-End and Kerberos-Hop-by-Hop. 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. Kaushik expires February 2001 [Page 2] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 RADIUS is a UDP based protocol with a very elementary security framework. Radius makes no provision to provide End to End security and provides Hop by Hop integrity protection and limited privacy protection using static symmetric transforms. With the exception of some attributes the RADIUS packet is transmitted in cleartext and thus is vulnerable to snooping. In addition RADIUS privacy protection uses a pre-configured key which is vulnerable to attack by snooping. End to End security is a key requirement for interdomain scenarios like roaming and shared services and even the Hop by Hop security that Radius provides might be insufficient for some cases. 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 end to end with the exception of the User-Name and Called-Station-Id attributes, these attributes are used by RADIUS proxies to forward RADIUS packets, and thus cannot be encrypted end to end. The RADIUS attributes added in this draft, Kerberos-End-To-End and Kerberos-Hop-By-Hop are never encrypted. RADIUS attributes, with the exception of Kerberos-End-To-End, Kerberos-Hop-By-Hop, 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-End-To-End, Kerberos-Hop-By-Hop attributes. The word "radius" is used as the keyword in the Kerberos service principal. The Kerberos V principal for a RADIUS server called "servername" in the realm "serverrealm" would be radius/servername.serverrealm@serverrealm. The NAS uses the kerberos service principal for service discovery i.e. 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. Kaushik expires February 2001 [Page 3] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 A valid cross domain Ticket Granting Ticket(TGT) must be cached on the Radius client prior to sending a Kerberized Radius request. Cross domain TGT acquisition is out of the scope of this draft and can happen based on inter domain trust or public key extensions like PKCROSS can be employed to obtain cross realm TGTs. The service principal ticket is acquired from the KDC prior to a Kerberos application exchange. The RADIUS client will send a KRB_TGS_REQ to the Ticket Granting Service (TGS) in order to the service principal ticket for the RADIUS server. The TGS will reply with a KRB_TGS_REP, containing a session key and Kerberos ticket to the RADIUS service. In case the service principal ticket is present in the credentials cache on the RADIUS client, the KRB_TGS_REQ will not be sent, but the credentials would be retrieved from the cache. The credentials would be cached on the Radius client for a non negligible period of time(can vary from a few hours to months) and the number of transactions between the Kerberized Radius clients and the KDC (KRB_TGS_REQ/KRB_TGS_REP) would be very small as compared to the transactions between the Kerberized Radius peers (KRB_AP_REQ/KRB_AP_REP). The Kerberized Radius operation would mostly involve dynamic symmetric key negotiation between Radius peers using the Kerberos Application exchange (KRB_AP_REQ/KRB_AP_REP). The symmetric keys negotiated would then be used to provide integrity protection and privacy protection for the Radius AVPs. In routing the Access-Request to the home RADIUS server, the NAI is typically used, as described in RFC 2486. For NAS to homeserver End-to-End security the NAS can determine whether the Access-Request will be served locally, or whether it needs to be proxied based on the NAI. The NAS would also need the hostname of the homeserver construct the End-to-End service principal. The hostname and port of a RADIUS homeserver can be determined as described in the section 3.4. Remote realm Kerberos Key Distribution Centres(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. 3.1 End-to-End Security using Kerberized Radius Kerberized Radius would provide end-to-end security between Radius peers, End-to-End security refers to security between the NAS domain and the homeserver. Implementations might have end-to-end security between the NAS and homeserver or between the NAS domain proxy server and the Radius homeserver. This draft can provide NAS to homeserver End to End security without a major compromise in NAS performance since the symmetric key operation and ticket caching make Kerberos exceptionally lightweight. This section uses the term Radius client which refers to a NAS or a NAS realm Radius proxy acting as a Radius client. Kaushik expires February 2001 [Page 4] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 The RADIUS client will start of by creating a KRB_AP_REQ message using the credentials present in the end-to-end service principal ticket. 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 homeserver to use its secret key to decrypt the Kerberos ticket. If end-to-end Kerberos is used, then an end-to-end MIC must be present. This prevents a downgrade attack in which an attacker deletes the end-to-end MIC and then modifies the reply. The integrity check message is generated as follows 1> Create the Integrity protected attribute list TLV if one or more Radius AVPS need to be end-to-end integrity protected, the list should be in order in which the Radius AVPs are present in the Radius AVP checksum block. This step is optional since a client might decide not to integrity protect any normal Radius AVPs end-to-end. 2> Create the Keberos Integrity Protection message (MIC) KRB_SAFE ( Radius code (header) + Encryption flag + Integrity Protected Attribute List TLV (optional) + MD5 (Radius AVP checksum block)) (optional) Encryption flag = 1 (if end-to-end encryption is used) = 0 (otherwise) In case there are attributes that need to be encrypted end-to-end then a KRB_PRIV message is created which uses the Kerberos end-to-end session key to encrypt the Radius AVPs. The format of the KRB_SAFE and KRB_PRIV messages has been specified in section 3.3 and section 3.4 respectively. The User-Name and Called-Station-Id attributes are never encrypted on an end-to-end basis since RADIUS proxies typically use these attributes for routing decisions. The Radius client would then create a Kerberos-EndtoEnd attribute which would contain the TLVs for the Kerberos authentication (KRB_AP_REQ), KRB_SAFE message, KRB_PRIV message and Integrity protected attribute list TLV. Details about the exact format of the Kerberos-EndtoEnd attribute can be found in section 6.2. Any intermediate RADIUS proxy would copy the Kerberos-EndtoEnd to a new packet along with the other RADIUS attributes. Thus, RADIUS proxy operation is transparent with respect to the end-to-end Kerberized RADIUS extensions. This would enable the Kerberized Radius extensions to work transparently through a conventional RFC2865 Radius proxy. On reception of the Access-Request or Accounting-Request, the Kerberized RADIUS home server would obtain the secret key for the service principal from the Kerberos keytab file. The server would extract the KRB_AP_REQ message from the Kerberos-EndtoEnd attribute and decrypt the enclosed Kerberos ticket using its secret key and obtain the Kerberos session key. Kaushik expires February 2001 [Page 5] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 This Kerberos session key is the same as the client session key. The server would then decrypt the Kerberos authenticator using the Kerberos session key and verify authenticator. This completes the Kerberos service authentication. In case of an error in Kerberos authentication, an Access-Reject is sent with a Kerberos-EndtoEnd attribute containing the KRB_ERROR message in the Kerberos authentication TLV. On successful Kerberos authentication , the server would extract the KRB_PRIV message from the privacy TLV if it is present in the Kerberos-EndtoEnd attribute. The encrypted Radius AVPs would be decrypted from the KRB_PRIV message using the Kerberos session key. After successful decryption of any encrypted Radius AVPs the server would extract the KRB_SAFE message and integrity protected attribute list from the Kerberos-EndtoEnd attribute. The KRB_SAFE message would always be present in the Kerberos-EndtoEnd attribute, the server would do the following to verify the integrity checksum 1> Check for the Integrity protected attribute list TLV in the Kerberos-EndtoEnd attribute and extract the list of integrity attributes if this TLV is present and create a block of data with the Radius AVPs specified in the integrity protected list in the same order as in the list. 2> KRB_SAFE (Radius code + Encryption Flag + Integrity Protected Attribute List TLV (if present) + MD5(Integrity Protected Radius AVPs (if present))) here Encryption Flag = 1 (if privacy TLV is present) = 0 (otherwise) 3> Verify the generated checksum against the checksum in the KRB5_SAFE message. Sucessful verification of the checksum completes the Kerberos operations on the Radius packet. The homeserver would have successfully performed Kerberos authentication, decryption (optional) and integrity check on the Radius packet. The Radius packet can then be 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 auth TLV in the Kerberos-EndtoEnd attribute. The end-to-end KRB5_SAFE message is generated in much the same way as the Radius client. Any Radius AVPs in the reply that need to protected end-to-end are added to the integrity protected block and the integrity protected attribute list TLV is created as well. If encryption is desired on a set of normal Radius AVPs then the KRB5_PRIV message is generated which would contain the Radius AVPs encrypted with the Kerberos session key. Kaushik expires February 2001 [Page 6] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 The homeserver would generate the Keberos-EndtoEnd attribute and add the Kerberos auth(KRB_AP_REP) TLV, integrity protection TLV (KRB_SAFE), privacy protection TLV (KRB_PRIV - optional) and the Integrity protected attribute list TLV (optional) and send back the Radius reply. On receiving an Access-Accept, Access-Reject, Access-Challenge or Accounting-Reply from the home server, the Radius client would perform the same set of operations as the homeserver to perform end-to-end Kerberos authentication, decryption (optional) and integrity verification. Upon successful Kerberos operation the reply would processed normally. 3.2 Hop by Hop Security using Kerberos End to End security is probably the most important requirement for Radius, but Radius hop by hop security itself is weak. Radius provides hop by hop integrity protection and encryption using statically configured keys. Moreover Radius doesn't encrypt anything other than the User-Password attribute. In certain cases there might be requirement to provide strong security on a hop by hop basis in addition to the end to end security requirement. This draft provides Hop by Hop Kerberos authentication for Radius and hop by hop privacy protection and integrity protection of the Radius AVPs. Hop by Hop security are exactly similar to the End to End security operations as discussed in the previous section. The only differences being 1> Kerberos-HopbyHop attribute is used to carry the hop by hop kerberos authenticator, KRB5_SAFE, KRB5_PRIV messages and the hop by hop MIC attribute list. The format of this attribute is exactly same as the Kerberos-EndtoEnd attribute. 2> The hop-by-hop KRB5_SAFE message is not mandatory, this is because the Radius header authenticator provide hop by hop integrity protection. 3> In case kerberos is employed for hop by hop security the kerberos session key should be used as the Radius secret. Hop by Hop security is totally independent of End to End security. The NAS or any intermediate Radius proxy might decide to employ Hop by Hop security by adding the Kerberos-HopbyHop attribute. This may be in addition to an End to End security present between the Radius client and homeserver but presence of End to End security is not mandatory for Hop by Hop security. Kaushik expires February 2001 [Page 7] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 3.3 Encryption operation The KRB_PRIV message carries the Radius AVP block encrypted in the Session Key. The Radius AVP block would be present in the user-data field in the EncKrbPrivPart message. As defined in RFC 1510, the following ASN.1 definition describes the KRB_PRIV message KRB-PRIV ::= [APPLICATION 21] SEQUENCE { pvno[0] INTEGER, msg-type[1] INTEGER, enc-part[3] EncryptedData } EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { user-data[0] OCTET STRING, timestamp[1] KerberosTime OPTIONAL, usec[2] INTEGER OPTIONAL, seq-number[3] INTEGER OPTIONAL, s-address[4] HostAddress, -- sender's addr r-address[5] HostAddress OPTIONAL -- recip's addr } The enc-part holds an encoding of the EncKrbPrivPart sequence encrypted under the session key. As defined in RFC 1510, the following ASN.1 definition describes the encrypted contents: 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 } Kaushik expires February 2001 [Page 8] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 3.4 Integrity Protection operation The KRB_SAFE message carries the integrity protected Radius attributes and other elements in the integrity message. The exact format of the integrity protection message is given in section 6.1.3. This message is carried along with a collision-proof checksum keyed with the session key. As defined in RFC 1510, the following ASN.1 definition describes the KRB_SAFE message KRB-SAFE ::= [APPLICATION 20] SEQUENCE { pvno[0] INTEGER, msg-type[1] INTEGER, safe-body[2] KRB-SAFE-BODY, cksum[3] Checksum } KRB-SAFE-BODY ::= SEQUENCE { user-data[0] OCTET STRING, timestamp[1] KerberosTime OPTIONAL, usec[2] INTEGER OPTIONAL, seq-number[3] INTEGER OPTIONAL, s-address[4] HostAddress, r-address[5] HostAddress OPTIONAL } As defined in RFC 1510, the following ASN.1 definition is used for a checksum: Checksum ::= SEQUENCE { cksumtype[0] INTEGER, checksum[1] OCTET STRING } 3.5 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. Kaushik expires February 2001 [Page 9] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 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. 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. Kaushik expires February 2001 [Page 10] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 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. 6.0 Attributes The Kerberos-EndtoEnd and Kerberos-HopbyHop 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 are reserved for implementation specific use, and 241-255 are reserved and should not be used. This document uses the following values: 92 Kerberos-EndtoEnd 93 Kerberos-HopbyHop 6.1 Kerberos-EndtoEnd Description The Kerberos-EndtoEnd attribute contains the End to End security parameters. The attribute contains the Kerberos authentication TLV (KRB_AP_REQ/KRB_AP_REP), privacy TLV (KRB_PRIV message), message integrity TLV (KRB_SAFE message) and the Integrity protected Attributes List TLV. Since all these kerberos messages put together would exceed 253 octets, multiple Kerberos-EndtoEnd attributes would be present in the RADIUS packet. 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-EndtoEnd Length Length of this attribute. Kaushik expires February 2001 [Page 11] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 String The value field of the Kerberos-EndtoEnd attributes contains multiple Type-Length-Value format messages. 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 ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- The possible values of the Type are 0 Kerberos Authentication message 1 Privacy protection message 2 Integrity Protection message 3 Integrity protected attribute list 6.1.1 Kerberos Authentication message Description This Kerberos Authentication message TLV carries the KRB_AP_REQ and KRB_AP_REP/KRB_ERROR messages. These messages are used for Kerberos mutual authentication and symmetric key exchange. A summary of the Kerberos Authentication message TLV 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 0 for Kerberos Authentication message. Length Length of the KRB_AP_REQ, KRB_AP_REP or KRB_ERROR message. String The KRB_AP_REQ, KRB_AP_REP or KRB_ERROR message. Kaushik expires February 2001 [Page 12] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 6.1.2 Privacy protection message Description This Privacy protection message TLV carries the KRB_PRIV message which contains encrypted Radius AVPs. This TLV would be present if the client has selected end to end encryption for one or more Radius attributes. A summary of the Privacy protection message TLV 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 0 for Kerberos Authentication message. Length Length of the KRB_SAFE message. String The KRB_SAFE message. 6.1.3 Integrity protection message Description This Integrity protection message TLV carries the KRB_PRIV message which contains the MIC computed over Radius code + Encryption Flag + Integrity protected attribute list TLV + MD5(integrity protected Radius attributes) To create the fourth element in the block, the Radius client would create a block of data with the Radius AVPs that need to be integrity protected and compute a MD5 signature over this block. The Integrity protection message TLV is mandatory but a Radius client may decide not to have end to end integrity protection for any of the "normal" Radius attributes in which the MIC would computed over Radius code + Encryption flag Encryption flag = 1 (if end to end encryption selected) = 0 (otherwise) Kaushik expires February 2001 [Page 13] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 A summary of the Integrity protection TLV 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 0 for Kerberos Authentication message. Length Length of the KRB_SAFE message. String The KRB_SAFE message. 6.1.4 Integrity protected attributes list Description This Integrity protected attributes list TLV carries the list of "normal" Radius attributes that are end to end integrity protected. This TLV is not mandatory and will not be present if a Radius client decides that none of the "normal" Radius attributes need end to end integrity protection. This TLV would also be protected by the integrity protection message. A summary of the Integrity protected attributes list TLV format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | Value ....... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 4 for Integrity protected attributes list Length 2 + 4 * Number of integrity protected "normal" Radius attributes. Kaushik expires February 2001 [Page 14] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 Value The value field is a list of integers, each item of the list would occupy four octets. Each 4 octet in the list is a Radius attribute type field and the list is filled in the same order as the Radius attributes appear in the block of integrity protected Radius AVPs. 6.2 Kerberos-HopbyHop The Kerberos-HopbyHop attribute contains the Hop by Hop security parameters which are used to provide Kerberos security services on a hop by hop basis. The format of the Kerberos-HopbyHop is exactly similar to the Kerberos-EndtoEnd attribute described in the previous section. Similar to the Kerberos-EndtoEnd attribute, the Kerberos-HopbyHop attribute would also contain the Kerberos authentication TLV (KRB_AP_REQ/KRB_AP_REP), privacy protection TLV (KRB_PRIV message), integrity protection TLV (KRB_SAFE message) and the Integrity protected attribute list TLV. Please refer to the previous section for the format of the Kerberos-HopbyHop attribute and the individual TLVs. Note: Radius clients can choose multiple modes of operation by having the Kerberos-EndtoEnd attribute or Kerberos-HopbyHop attribute or both part of the Radius packet. The End to End mode where just the Kerberos-EndtoEnd attribute is present is the most useful mode for Radius. The End to End with Hop by Hop is an extension of the End to End where some intermediate proxies use Kerberos for hop by hop security. This mode might be used in some special cases where hop by hop security is desired across some insecure hops. This draft also provides for a Hop by Hop mode where Kerberos is used for key management instead of static key association provided for Radius. The advantage of using Kerberos for hop by hop security is dynamic key association which would provide stronger security. A summary of the Kerberos-EndtoEnd and Kerberos-HopbyHop attributes is given below: -------------------------------------------------------- | Attribute | Attribute | Attribute | | | Added By | Read by | -------------------------------------------------------- | Kerberos-EndtoEnd | NAS or NAS | Radius | | | realm proxy | homeserver | -------------------------------------------------------- | Kerberos-HopbyHop | Any Radius | Next hop Radius | | | proxy | proxy/homeserver | -------------------------------------------------------- Kaushik expires February 2001 [Page 15] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 7.0 Implementation Notes This section we examine how the Kerberized RADIUS extensions can be implemented on the client and server using a standard Kerberos library. Following is a list of Kerberos v5 library calls that would be employed to implement the Kerberized Radius extensions. krb5_mk_req - This call would be used by the Radius client to initialize a new Kerberos security context. This call would would check whether the service principal ticket is present in the cache and if not acquire the service principal ticket from the KDC (KRB_TGS_REQ). It would then create the KRB_AP_REQ message using the credentials present in the service principal ticket. This call would also process the KRB_AP_REP received back from the Radius server to complete the mutual authentication. krb5_rd_rep - This call would be used by a Radius server to process the KRB_AP_REQ request from the client. It would perform the service authentication and retrieve the Kerberos session key. This call would also generate the KRB_AP_REP message. krb5_mk_priv - This call would be used by the Radius client and server to encrypt the block of Radius attributes that need privacy protection using the kerberos session key. krb5_rd_priv - This call would be used by the Radius client and server to decrypt the block of encrypted Radius attributes using the kerberos session key. krb5_mk_safe - This call would be used by the Radius client and server to create the Integrity checksum using the kerberos session key. krb5_rd_safe - This call would be used by the Radius client and server to verify the Integrity checksum using the kerberos session key. 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. Kaushik expires February 2001 [Page 16] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 9.0 Security Considerations This draft determines whether to use Kerberos purely on the basis of the existence or non-existence of a Kerberos service principal. This presents an opportunity for a downgrade attack wherein because an attacker can spoof an error message from the KDC and make the Kerberized Radius client use "vanilla" Radius which would compromise end to end security. Implementations should provide users with a policy knob which would prevent Kerberized Radius clients from falling back to "vanilla" Radius in case they encounter an error while acquiring the service principal ticket from the KDC. 10.0 Acknowledgments I would like to thank Bernard Aboba, Jeffrey Hutzelman, Sam Hartman 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-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. Kaushik expires February 2001 [Page 17] Internet-Draft Radius Security Extensions using Kerberos v5 August 2000 12.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 13.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 18]