EAP Authentication for SIP & HTTP V. Torvinen (Ericsson), J. Arkko (Ericsson), A. Niemi (Nokia),

Current SIP Authentication Situation HTTP basic HTTP digest PGP Existing security can be used at an outer layer Client SIP-server AAA-server TLS, IKE/IPsec New DIAMETER extensions Certain SIP-specific methods exist. Work going on to refine these. Work has started to extend DIAMETER to support HTTP authentication methods

How Does This Work Fit to the Picture? HTTP basic HTTP digest HTTP EAP PGP Client SIP-server AAA-server TLS, IKE/IPsec New DIAMETER Extensions Reusing existing RADIUS and DIAMETER We define a new alternative HTTP authentication method which is - more flexible than previous ones - takes less roundtrips than e.g. IKE - implies no changes protocols or SIP server as new auth mechanisms are invented We reuse existing AAA protocols directly

Background for Our Work Third generation mobile networks will provide a multimedia system that runs over IP and uses SIP The 3GPP is working on security to ensure such multimedia service can be trusted and can be billed for One of the issues is the authentication of devices/users towards the home operator during registration We’d like to define a mechanism that satisfies the requirements of 3GPP networks as well as other uses of SIP 3GPP needs UMTS AKA and other authentication methods - EAP (RFC 2284) for allow many methods

3GPP Requirements Use less roundtrips per authentication event – Use SIP authentication rather than an outer layer protocol such as TLS or IKE. Find light but secure authentication method – Do not apply HTTP basic/digest or PGP because they are either insecure or too heavy. – Do not develop a new method Authentication is typically applied at registration time 3GPP needs to use UMTS AKA for authentication –Devices already have a SIM card for this purpose –For access independence and ability to use laptops without SIM cards, other methods also highly desirable –A generic scheme such as GSS_API, SASL, EAP is therefore desired

Introduction to EAP Extensible Authentication Protocol, RFC 2284 Originally used in PPP Being adopted for WLANs, possibly for Bluetooth Extensible protocol framework: –Same protocol can carry various authentication methods –AAA protocols for carrying EAP exist (RADIUS and DIAMETER) –Some have already been defined for EAP such as passwords, token-cards, TLS, GSS_API, GSM, UMTS AKA, etc. –New ones can be defined –Clients and AAA servers must support the method they use –NASes, proxies, etc. can ignore what happens inside EAP

SIP Authentication Schemes HTTP EAP SIP HTTP AuthenticationPGP HTTP Digest HTTP Basic EAP AKA EAP GSMEAP TLSEAP...EAP Token Card

Concrete Authentication Example in SIP REGISTER sip:… SIP/2.0 SIP/ Authentication Required WWW-Authenticate: eap eap-packet REGISTER sip:… SIP/2.0 Authorization: eap eap-packet SIP/ OK Authentication-info: eap-packet User agent Reg. server May be repeated

Conclusions and Going Forward Looks like HTTP EAP provides a flexible authentication scheme for SIP, and allows us to leverage existing EAP methods Feedback is sought on the applicability, security and other aspects of this approach We’d like this work to be a work item of the WG Further work is needed at least on the following issues: –How headers and subsequent SIP messages can be protected by the keys generated by some EAP methods –While the authentication can reuse DIAMETER NASREQ extension, it may still be necessary to define new attributes that tell the DIAMETER server more about what is happening at SIP level (3GPP has also special requirements and needs an own DIAMETER extension).