Kerberized Handover Keying: A A Kerberized Handover Keying: Media- -Independent Handover Key Independent Handover Key Media Management Architecture Management Architecture Yoshihiro Ohba (yohba@tari.toshiba.com yohba@tari.toshiba.com) ) Yoshihiro Ohba ( Toshiba America Research, Inc. (USA) Toshiba America Research, Inc. (USA) Subir Das Das ( (subir@research.telcordia.com subir@research.telcordia.com) ) Subir Ashutosh Dutta Dutta ( (adutta@research.telcordia.com adutta@research.telcordia.com) ) Ashutosh Telcordia Technologies (USA) Technologies (USA) Telcordia Aug 27, 2007 Aug 27, 2007 MobiArch07 MobiArch07 1 1
Problem description (1/2) Problem description (1/2) • • Wireless access networks require cryptographic data protection at link t link- -layer layer Wireless access networks require cryptographic data protection a • • Enabling cryptographic data protection requires security signaling ng Enabling cryptographic data protection requires security signali • • Security signaling takes time, especially for peer- -entity authentication in a entity authentication in a Security signaling takes time, especially for peer roaming environment where authentication credentials are stored roaming environment where authentication credentials are stored in a AAA in a AAA server server – – AAA servers are typically located away from access networks AAA servers are typically located away from access networks • • IETF HOKEY WG is working on EAP (Extensible Authentication Protocol) col) IETF HOKEY WG is working on EAP (Extensible Authentication Proto signaling optimization based on two approaches signaling optimization based on two approaches – Pre- -authentication: authentication: a proactive handover optimization technique by which a peer – Pre runs EAP for a candidate target authenticator from the serving access network – Low- -latency Re latency Re- -authentication: authentication: an extension to EAP to minimize message – Low roundtrips by utilizing keying material generated by a previous EAP session Aug 27, 2007 Aug 27, 2007 MobiArch07 MobiArch07 2 2
Problem description (2/2) Problem description (2/2) • • Pre- -authentication applicability is limited to environments authentication applicability is limited to environments Pre where proactive signaling can take effect proactive signaling can take effect where – Optimization for reactive operation is missing – Optimization for reactive operation is missing • • Low- -latency re latency re- -authentication still requires authentication still requires Low communication to an AAA server (in home or visited communication to an AAA server (in home or visited network) after handover network) after handover – Difficult to support real Difficult to support real- -time applications time applications – We propose another approach using Kerberos to address We propose another approach using Kerberos to address these issues these issues Aug 27, 2007 Aug 27, 2007 MobiArch07 MobiArch07 3 3
Kerberos overview Kerberos overview • • Kerberos is a three- -party authentication and key party authentication and key Kerberos is a three management protocol based on symmetric keys management protocol based on symmetric keys • • There are three principals in Kerberos; a client, a server, There are three principals in Kerberos; a client, a server, and a key distribution center (KDC) and a key distribution center (KDC) • • KDC provides two special servers: an Authentication KDC provides two special servers: an Authentication Server (AS) and a Ticket Granting Server (TGS) Server (AS) and a Ticket Granting Server (TGS) • • It is assumed that each client and server has a pre- - It is assumed that each client and server has a pre established trust relationship with KDC based on a secret established trust relationship with KDC based on a secret key key Aug 27, 2007 Aug 27, 2007 MobiArch07 MobiArch07 4 4
Kerberos overview (cont’ ’d) d) Kerberos overview (cont • • In Kerberos, a session key is is generated by the KDC and distributed to the generated by the KDC and distributed to the In Kerberos, a session key client client – The session key is used by the client and server to securely establish a is used by the client and server to securely establish an n – The session key application session session application • • The client then distributes the session key to the server using a a ticket ticket, , or a or a The client then distributes the session key to the server using record generated by the KDC to help a client authenticate itself to a server to a server record generated by the KDC to help a client authenticate itself • • The ticket contains the identity of the client, a session key, a he ticket contains the identity of the client, a session key, a timestamp timestamp T and other information and other information – – The session key is encrypted using the server's secret key shared only with the The session key is encrypted using the server's secret key shared only with the KDC KDC • • The Kerberos protocol consists of three exchanges where the initial The Kerberos protocol consists of three exchanges where the init ial exchange is performed only once exchange is performed only once – – AS- AS -REQ/AS REQ/AS- -REP exchange for acquisition of a TGT (Ticket Granting Ticket) REP exchange for acquisition of a TGT (Ticket Granting Ticket) – TGS- -REQ/TGS REQ/TGS- -REP exchange for acquisition of a ticket used for the server REP exchange for acquisition of a ticket used for the server – TGS – AP- -REQ/AS REQ/AS- -REP exchange for installation of the ticket to the server REP exchange for installation of the ticket to the server – AP Aug 27, 2007 Aug 27, 2007 MobiArch07 MobiArch07 5 5
Kerberos sequence Kerberos sequence C S KDC AS_REQ TGT acquisition AS_REP TGS_REQ TGS_REP Per-server ticket acquisition AP_REQ AP_REP Present Ticket and get access to S S: Application Server C: Application Client KDC: Key Distribution Center Aug 27, 2007 Aug 27, 2007 MobiArch07 MobiArch07 6 6
KHK in a nutshell KHK in a nutshell • A mobile node and an authenticator act as a client or a server of Kerberos • The roles of client and server can be reversed depending on the timing when a ticket is delivered to the authenticator (role reversing) • Two modes of operation Proactive mode is the case in which ticket delivery to the MN happens before – the handover – Reactive mode is the case in which ticket delivery to the MN happens after the handover • Proactive mode is more optimized than reactive mode since it does not require for a mobile node to communicate with KDC after handover • In proactive mode, the signaling latency after handover is expected to be less than 20msec (comparable to IEEE 802.11i 4-way handshake) • KHK does not require an authenticator to create any state for a mobile node before handover even in proactive mode (i.e., more efficient than pre- authentication) Aug 27, 2007 Aug 27, 2007 MobiArch07 MobiArch07 7 7
Proactive mode Proactive mode MN (Client) KDC AS-REQ AS-REP D1,D2 TGS-REQ (A1), TGS-REQ (A2) TGS-REP (T1), TGS-REP (T2) A1 (Server) H1 AP-REQ (T1) A2 (Server) AP-REP KRB-SAFE or SAP Ai: Authenticator H2 Ti : Ticket for Ai AP-REQ (T2) Di: Event “Discovered Ai” AP-REP Hi: Event “Switched to Ai” KRB-SAFE or SAP Aug 27, 2007 Aug 27, 2007 MobiArch07 MobiArch07 8 8
Reactive mode Reactive mode MN (Server) Authenticator (Client) KDC H Trigger (MN) TGS-REQ (MN) TGS-REP (T) AP-REQ AP-REP KRB-SAFE or SAP T : Ticket for MN H: Event “Switched to Authenticator” Kerberos role is reversed between MN and Authenticator (Role Reversing) Aug 27, 2007 Aug 27, 2007 MobiArch07 MobiArch07 9 9
Authorization and accounting Authorization and accounting • Kerberos tickets also carry authorization • Kerberos tickets also carry authorization information information • The authorization information must come from • The authorization information must come from AAA AAA – KDC needs to be an AAA client KDC needs to be an AAA client for authorization for authorization – • Accounting is still performed at each • Accounting is still performed at each authenticator authenticator – Authenticators are an AAA client Authenticators are an AAA client for accounting for accounting (as (as – well as initial authentication) well as initial authentication) Aug 27, 2007 Aug 27, 2007 MobiArch07 MobiArch07 10 10
Authorization and accounting Authorization and accounting (cont’ ’d) d) (cont Authorization Authorization Authorization information over AAA Authorization information over AAA information over information over protocol protocol Kerberos (proactive Kerberos (proactive KDC mode) mode) AAA infrastructure AAA Infrastructure Mobile Node Authorization information Authorization information over Kerberos (reactive over Kerberos (reactive Authenticator Accounting information over AAA Accounting information over AAA mode) mode) protocol protocol Aug 27, 2007 Aug 27, 2007 MobiArch07 MobiArch07 11 11
Recommend
More recommend
