Radius Security Extensions using Kerberos V5 - PowerPoint PPT Presentation

About This Presentation
Title:

Radius Security Extensions using Kerberos V5

Description:

Makes use of DNS for discovery of remote realm Radius server and remote realm ... use either of these attributes to lookup the Radius homeserver and then forward ... – PowerPoint PPT presentation

Number of Views:67
Avg rating:3.0/5.0
Slides: 10
Provided by: engineerin107
Category:

less

Transcript and Presenter's Notes

Title: 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_at_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_at_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_at_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_at_HOM
    EREALM.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.
Write a Comment
User Comments (0)
About PowerShow.com