Radius Security Extensions using Kerberos V5

1. Radius Security Extensions using Kerberos V5 draft-kaushik-radius-sec-ext

2. Kerberos Operation (Mutual Authentication) • AS and TGS are components of the Key Distribution Center. • 1 - KRB_AS_REQ - Get the Ticket Granting Ticket • 2 - KRB_AS_REP - AS replies with the TGT. • 3 - KRB_TGS_REQ - Obtain a ticket for the service principal. You are not prompted for a password since reply would be encrypted with the key present in t he Ticket Granting Ticket (TGT). • 4 - KRB_TGS_REP - Ticket Granting Server responds with ticket for the service principal and the session key. • The ticket is encrypted with the servers key and the session key would be encrypted with the key sent in the Ticket Granting ticket. The Client would decrypt the session key and save it. • 5 - KRB_AP_REQ - The Client would send the Application request which contains the Ticket received from the TGS and the authenticator to the verifier. The authenticator is generated by the Client and encrypted with the session key. • 6 - KRB_AP_REP - The verifier would first decrypt the ticket and extract the session key. The key used to decrypt the ticket would be stored in a key tab file. The verifier would then decrypt the authenticator using the session key and authenticate the client. On successful authentication the Verifier would reply back with an authenticator for mutual authentication. • The authenticator sent back is verified by the Client. On successful mutual authentication a Kerberos security context is created.

3. Key points of the draft • Kerberos used for authentication and encryption. Uses mutual authentication mode of kerberos which has been explained in the previous slide. • Kerberos security contexts setup across Radius peers using Radius protocol to carry Kerberos messages for context establishment. • Supports Hop by Hop and End to End Proxy operation. • Extends the normal and proxy operation of Radius defined in RFC2865. • Fully backward compatible and can work through existing Radius servers and proxies. • Does not change the basic Radius operation, for e.g verification of Radius header authenticator is a redundant operation with Kerberos authentication also being done but still the verification of Radius header authenticator is retained to maintain backward compatibility. • A prerequisite is that the Ticket Granting Ticket should have been already obtained. • Makes use of DNS for discovery of remote realm Radius server and remote realm Key Distribution Center (KDC).

4. Normal Mode Kerberized Radius

5. Normal Mode Kerberized Radius Operation • Step1: NAS sends KRB_TGS_REQ to Ticket Granting Service. The service principal would be of the form radius/radserver@REALM.COM • Step 2: KDC sends back with the ticket in the KRB_TGS_REP. • Step 3: NAS constructs Access_Request with the following new attributes Kerberos-Data - Contains the KRB_AP_REQ message which contains the Kerberos authenticator and Kerberos Ticket. Kerberos-Mode - set to 0 or 1 based on encryption of attributes. Kerberos-Crypt - In case Kerberos-Mode is set to 1, then this attribute is present and contains the encrypted block of all attributes • Step 4: Radius Server would first perform Kerberos authentication and then proceed to decrypt the attributes in case encryption is selected. • Step 5: Radius Server would send back Access_Accept, Access_Reject or Access_Challenge based on Radius operation.

6. End to End Proxy Mode

7. End to End Proxy Mode Operation • Only one Kerberos Security context created. This Kerberos security context is created between the NAS and the homeserver. • Step 1: The NAS would send a KRB_TGS_REQ to the Ticket Granting Server. Service principal is radius/homeserver@HOMEREALM.COM. The NAS would discover the homeserver using the DNS SRV RR and the remote realm KDC would be discovered using DNS as well. • Step 2: The NAS would then create the Access_Request similar to the normal mode Kerberized Radius operation with Kerberos-Mode attribute set to 20. Encryption is mandatory since this is a cross realm operation and the Kerberos-Crypt attribute would contain the encrypted block of attributes. • Step 3: The Radius proxy would receive the request, the User-Name and the Called-Station-Id would never be encrypted. The proxy would use either of these attributes to lookup the Radius homeserver and then forward the request to the homeserver. The Kerberos authentication and encryption operation would be totally transparent to the Radius proxy. • Step 4: The homeserver would receive the request and first perform the Kerberos authentication and then decrypt the attributes. The homeserver would then construct a reply based on the Radius operation.

8. Hop by Hop Proxy Mode

9. Hop by Hop Proxy Mode Operation • Kerberos Security Context created across each hop. • Step 1: The NAS would send a KRB_TGS_REQ to the Ticket Granting Server. Service principal is radius/proxyserver@ROAM_ISP_REALM.COM. • Step 2: The NAS would then create the Access_Request similar to the normal mode Kerberized Radius operation with Kerberos-Mode attribute set to 20 or 21 based on whether encryption is required. • Step 3: The Radius proxy would receive the request and first perform Kerberos authentication and then decrypt the Radius attributes in case encryption was selected (mode = 21)Radius proxy. The Radius proxy would then use the User-Name or Called-Station-Id attribute to lookup the homeserver. The proxy would then would send a KRB_TGS_REQ to the Ticket Granting Server of the homerealm. Service principal radius/homeserver@HOMEREALM.COM • Step 4: The Radius proxy would then create a new Access_Request and forward it to the homeserver. Encryption is mandatory for cross realm hops and Kerberos-Mode would be set to 21. • Step 5: The homeserver would receive the request and first perform the Kerberos authentication and then decrypt the attributes. The homeserver would then construct a reply based on the Radius operation.