Radius Security Extensions Using Kerberos V5

1
Radius Security Extensions Using Kerberos V5

• draft-kaushik-radius-sec-ext

2
About this draft

• Attempt to address problems with AAA security,
  especially the problems in inter domain
  operations.
• Kerberos used to provide authentication,
  encryption and data integrity.
• Radius was a chosen since it is the base protocol
  for AAA and it was possible to implement the
  extensions and look at performance issues.

3
Key points of the draft

• 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.
• Fully backward compatible and can work through
  existing Radius servers and proxies.
• A prerequisite is that the Ticket Granting Ticket
  should have been already obtained. PKINIT can be
  employed to obtain TGT.
• Makes use of DNS for discovery of remote realm
  Radius server and remote realm Key Distribution
  Center (KDC).

4
Kerberos Operation (Mutual Authentication)
5
Kerberos Operation

• 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.
• 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.
• 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.

6
Summary of Changes

• Three new Radius attributes.
• Kerberos Mode - mode of operation.
• Kerberos Data - Carries the Kerberos messages
  (KRB_AP_REQ and KRB_AP_RES)
• Kerberos Crypt - Carries the block of encrypted
  AVPs or the Integrity Checksum of the AVP block.

7
Normal Mode Kerberized Radius
8
End to End Proxy Mode
9
Hop by Hop Proxy Mode
10
Advantages of Kerberos

• Mutual authentication of both the client and the
  server
• Simple inter domain trust management
• Symmetric key operation and non negligible ticket
  lifetime reduces the computational intensity.
• Kerberos can be easily implemented on a embedded
  devices.
• Small code size requirements.
• Kerberos is entirely based on open standards with
  a well tested and widely understood reference
  implementation.
• Kerberos is a mature standard which has been
  scrutinized cryptologists and security experts

11
What about Kerberized Diameter

• Radius is a stateless protocol and every request
  and response would need a new security context
• Kerberos Security contexts could be created and
  saved for the length of a Diameter session.
• New composite mode which combines End to End and
  Hop by Hop modes.
• Kerberos support for Public Key Security.

12
End to End and Hop by Hop
13
End to End and Hop by Hop

• End to End and Hop by Hop themselves dont solve
  all inter domain problems.
• In most AAA scenarios there is need for certain
  attributes to be encrypted attributes end to end
  and certain other attributes to be visible on a
  hop by hop.
• Composite mode would enable certain attributes to
  be encrypted on an end to end basis and certain
  other attributes to be decrypted/verified and
  re-encrypted/resigned on a hop by hop basis.