SIPPING IETF51 3GPP Security and Authentication

Peter Howard
3GPP SA3 (Security) delegate peter.howard@vodafone.com

3GPP IP Multimedia Subsystem (Release 5)

Cx interface based on Diameter SIP proxies get authorisation and authentication information
GGSN SGSN RAN

HSS

Home

S-CSCF I-CSCF
REGISTER/INVITE REGISTER/INVITE

UA

P-CSCF
REGISTER/INVITE

Visited
SIP-based interfaces PS domain SIP proxy servers

3GPP Release 5 Security

Packet Switched (PS) domain
access security features retained from 3GPP Release 99 specifications

IP Multimedia Subsystem (IMS) domain

new access security features to be specified
to protect the access link to the IMS domain independent of underlying PS domain security features

network domain security features to protect signalling links between network elements with the IMS domain

IP Multimedia Subsystem: Access Security

Draft 3GPP TS 33.203
4. Protection of SIP signalling using agreed session key 1. Distribution of authentication information

HSS

Home

S-CSCF
GGSN SGSN RAN

I-CSCF
REGISTER/INVITE

REGISTER/INVITE

UA

P-CSCF
REGISTER/INVITE

Visited

3. Session key distribution

2. Mutual authentication and session key agreement

IP Multimedia Subsystem: Network Domain Security

Draft 3GPP TS 33.210

HSS

Home

S-CSCF
GGSN SGSN RAN

I-CSCF
REGISTER/INVITE

REGISTER/INVITE

UA

P-CSCF
REGISTER/INVITE

Visited

Per-hop protection of signalling using IPsec/IKE

Access Security: Authentication Principles

3GPP authentication protocol (3GPP AKA)
based on secret key stored in UAs tamper-proof subscriber identity module (SIM) and in the HSS

Authentication check located in S-CSCF Working assumption is to authenticate only at SIP registrations with on-demand re-authentication requiring re-registration Use SIP authentication rather than an outer layer protocol such as TLS or IKE in order to minimise roundtrips

Integration of Authentication Protocol into DIAMETER and SIP

Distribution of authentication information to SCSCF using DIAMETER
distribution of authentication vectors for 3GPP AKA

Integration of authentication protocol into SIP registration

3GPP AKA protocol between UA and S-CSCF distribution of session key to P-CSCF

Possible Information Flow for Authentication and Session Key Establishment (from draft 3GPP TS 33.203)

Changed to 407 Proxy Authentication Required

Cx-Put Cx-Pull

Use of Extensible Authentication Protocol (EAP)

There is a desire to minimise impact on protocols and equipment if 3GPP AKA is updated or if other schemes are used
a generic/extensible scheme to carry the authentication messages is desirable candidates include SASL, EAP, GSS_API current working assumption is EAP which has much of the necessary machinery in place

EAP AKA in SIP

SIP HTTP Authentication HTTP Basic HTTP Digest PGP HTTP EAP

EAP Token Card

EAP TLS

EAP GSM

EAP AKA

EAP ...

Concrete Authentication Example in SIP

1. p REGISTER sip: SIP/2.0 Authorization: eap base64_eap_identity_response ... 2. n SIP/2.0 407 Proxy Authentication Required WWW-Authenticate: eap base64_eap_aka_challenge_request 3. p REGISTER sip: SIP/2.0 Authorization: eap base64_eap_aka_challenge_response 4. n SIP/2.0 200 OK WWW-Authenticate: eap base64_eap_aka_success ...

EAP AKA in DIAMETER

DIAMETER base

EAP Extensions

EAP Token Card

EAP TLS

EAP GSM

EAP AKA

EAP ...

Access Security: Security Mode Establishment between UA and P-CSCF

Determines when to start applying protection and which algorithm to use
includes secure algorithm negotiation

Uses session key derived during authentication Integration into SIP registration with no new roundtrips

Access security: Protection of SIP signalling between UA and P-CSCF

Integrity protection of SIP signalling between UA and P-CSCF Uses session key derived during authentication Symmetric scheme because of efficiency concerns Candidate mechanisms include modified CMS and ESP

IP Multimedia Subsystem: Access Security Documentation

High level architecture
TS 23.228 (SA2) TS 33.203 (SA3)

3GPP

IETF

Other specs (e.g. AKA) (SA3)

SIPPING WG

TS 24.228 (CN1)

TS 29.228 (CN4)

TS 24.229 (CN1)

TS 29.229 (CN4)

AAA, PPPEXT, IPsec,

Protocol detail

Summary of 3GPP dependencies on IETF relating to security

3GPP AKA in EAP
draft-arkko-pppext-aka-00.txt

EAP and session key transport in SIP

draft-torvinen-http-eap-00.txt (to appear)

EAP and session key transport in DIAMETER SIP extensions to support security mode establishment

References
Draft 3GPP TS 33.203, Access security for IP-based services (Release 5). Draft 3GPP TS 33.210, Network domain security; IP network layer security (Release 5). J. Arkko and H. Haverinen, EAP AKA Authentication draft-arkko-pppext-aka-00.txt. V. Torvinen, J. Arkko, A. Niemi, HTTP Authentication with EAP, draft-torvinen-http-eap-00.txt (to appear). L. Blunk, J. Vollbrecht, PPP Extensible Authentication Protocol (EAP), RFC 2284. P. Calhoun et al. DIAMETER NASREQ Extensions, draft-ietf-aaa-diameter-nasreq-06.txt.

Questions?
Peter Howard
peter.howard@vodafone.com

Authentication and Key Agreement Protocol (3GPP AKA)

ISIM/UA S-CSCF HSS

Authentication vector request Authentication vector response

Three party protocol Two-pass mutual authentication protocol between UA and S-CSCF Authentication response Each authentication vector is good for one authentication Distribution of session Authentication vectors can be key to P-CSCF P-CSCF distributed in batches to minimise signalling/load on HSS
Authentication request

Other IP Multimedia Subsystem Security Issues (1)

Hide callers public ID from called party
by encrypting remote party ID header at callers SCSCF and decrypting by same S-CSCF is there a requirement to hide callers IP addresses that are dynamically assigned?

Network configuration hiding

mechanism being developed to hide host domain name of CSCFs and number of CSCFs within one operators network

Other IP Multimedia Subsystem Security Issues (2)

Session transfer
guidance on security aspects based on GSM call transfer feature
authorisation and accounting of transferred leg needs to involve transferring party who has dropped out of session should there be a limit to the number of transferred sessions? should final destination be hidden from calling party?

Security aspects of other IP multimedia subsystem services? End-to-end security