Peeking into IETF Security Standardization
description
Transcript of Peeking into IETF Security Standardization
1
Peeking into IETF Security Standardization
3rd ETSI Security Workshop, Jan. 2008
Hannes Tschofenig
2
The IETF
110+ working groups in 8 areas
Security work in the Security Area and also in other working groups.
Applications
Area
General
Area
RAI
Area
Internet
Area
Routing
Area
Security
Area
Transport
AreaSIP SIPPING AVT GEOPRIV
RAI
SIMPLEMMUSIC
…
O & M
Area
3
SIP Identity
RFC 4474
RFC 3261
S/MIME
RFC 3325
P-Asserted-Identity
SIP SAML
SIP
CERT
RFC 3261
Connected
Identity
RFC 3323
SIP Privacy
Identity in SIP
UA-Driven Privacy
Mechanism for SIP
4
SIP in a Nutshell
Session Initiation Protocol (SIP) [RFC 3261] :
•SIP is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.
•These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.
SIP / RTP / RTCP
Proxy BSIP/SDP
Alice
Proxy A
SIP/SDP SIP/SDP
Bob
5
Early Approaches
RFC 3261
• S/MIME: Provides a way to sign the headers and encrypt the body of a SIP request– Copy of the SIP headers can be added to the body and signed with sender’s
private key
– Relies on the sender and recipient to have common trust anchors
• Proxies using mutual TLS connections may build a chain of trust so that only the first proxy in the chain has to authenticate the sender.
RFC 3325: P-Asserted-Identity
• After authenticating the sender, the proxy can add P-Asserted-Identity header to the SIP message. This header carries the authenticated identity (SIP URI) of the sender.
• P-Asserted-Identity header is protected only in a hop-by-hop fashion between the SIP proxies along the path. The mechanism can only be used within a trust domain in which the SIP proxies and UAs communicate securely and the proxies share a mutual trust.
RFC 3893: SIP Authenticated Identity Body (AIB) Format
• Defines contents of digitally signed message/sipfrag body to authenticate the sender
6
RFC 3323: Privacy in SIP
Guidelines for providing maximal user-provided privacy
• Using anonymous values for display names and URIs in From header and user part of the Contact header
Concept of Privacy Service provided by the network
• Often provided by the local outbound proxy but if hiding the domain of the sender is needed, then 3rd party Privacy Service should be used. Works as a B2BUA.
• UA adds a Privacy header to communicate privacy requirements to the network– Values specified in RFC 3323: “header”, “session”, “user”, “none”, “critical”
• Privacy Service consumes values of Privacy header and provides requested services– “header”: obscures/removes e.g. Via, Contact & Record-Route headers
– “session”: modifies SDP to hide the addresses and ports of the user
– “user”: replaces display names and URIs in From and Contact like the UA could do, removes also Subject, Call-Info, Organization, User-Agent, Reply-To and In-Reply-To.
– “critical”: rejects the requests if requested privacy can not be provided
– “id”: (RFC 3325) remove P-Asserted-Identity header at the edge of trust domain
7
RFC 4474: An overview of operation
Sending SIP requests over an Authentication Service
• The sender has to populate the From header with the registered AoR
• When sending the request, the sender contacts a SIP proxy in his local domain providing authentication service securely (e.g. over TLS)
Operation of an Authentication Service within the user’s domain
• The authentication service authenticates the sender (e.g. by HTTP Digest) and verifies the SIP identity written into the From header of the SIP request
• The authentication service authorizes population of From header and digitally signs the message before forwarding it towards the ultimate recipient, using Identity header
• Within the forwarded SIP request the authentication service also provides a reference (HTTP URI) to its own domain certificate, using Identity-Info header
Actions by the recipient of the request to verify the authenticated identity
• Fetches and validates the certificate of the authentication service
• Verifies the signature of the SIP request and the identity of the sender
• Checks the value of signed Date header to protect against replay attacks
8
Authentication Service within local SIP proxy
AuthenticationService ofhome.com
SIPcloud
INVITE sip:[email protected] SIP/2.0
From: sip:[email protected]
Authorization: ….
Content-Type: application/SDP
Sends a SIP requestand adds SIP AORof the sender intothe From header
Authenticates theuser with HTTP Digest, verifies the From URI and adds a signature to the request
TLS
Fetches thecertificate ofhome.com andvalidates it.Verifies thesignature andsender’s identity.Checks Date hdr.
INVITE sip:[email protected] SIP/2.0
From: sip:[email protected]
Date: Fri, 1 Jun 2007 13:29:00 GMT
Identity: <signed hash of sipfrag>
Identity-Info: https://home.com/cer
Content-Type: application/SDPAdds alsoa referenceto home.comcertificate tothe request
Checks thevalue of Dateheader or addssuch if missing
https://home.com/cerstoring the certificate
UARemote
UA
9
Connected Identity (RFC 4916)
SIP request is targeted to a specific callee (SIP URI) but ultimately the connection may be created with someone else
• SIP proxies may retarget the request for several reasons
• Call might be transferred automatically or manually after the initial answer
Connected Identity describes the solution
• Reuses the mechanisms defined in RFC 4474 for an UPDATE or re-INVITE request sent by the callee mid-dialog
• UA supporting this extension must add “from-change” tag to Supported header
• Allows the callee to change the value of From header to identify him/herself, instead of using the original value of the To header used when the dialog was created.
• The caller must update the value of To header accordingly for the subsequent requests within the dialog.
10
SIP Cert: draft-ietf-sip-certsAssumptions
• client certificates will be self-signed and users will have many devices per identity
Solution: User managed credential storage
• Upload to the credentials (certificate & private key) in storage using PUBLISH
• Download to other devices using SUBSCRIBE/NOTIFY: event package “credential”– The private key within the NOTIFY might be encrypted with a shared secret
Certificate discovery mechanism – for retrieving certificates of other users
• SUBSCRIBE/NOTIFY: event package “certificate”
• SIP Identity offers binding the self-signed certificate to a known certificate authority– Therefore, a hybrid model
Certificate revocation as a byproduct
• Subscription refreshes
• Asynchronous certificate push to replace a revoked certificate
11
Credential Service in SIP
CredentialService
User Agent Y
ewing.com
User Agent
User Agent X
PUBLISHw/ Digest + TLSEvent: credential(certificate & private key)
SUBSCRIBE/NOTIFYw/ Digest + TLSEvent: credential(certificate & private key)
NOTIFYEvent: certificate(Bob’s certificate)
AuthenticationService
NOTIFY+IdentityEvent: certificate(Bob’s certificate)
SUBSCRIBEsip:[email protected] Event: certificate
ewing.com
SUBSCRIBEsip:[email protected] Event: certificate
12
SIP SAML: draft-ietf-sip-saml
Based on requirements and scenarios defined in RFC 4484
Defines a SAML profile and SAML binding in collaboration with SIP
• To accommodate richer authorization mechanisms and enable trait-based authorization based on roles or traits instead of (or in addition to) SIP Identity
• Defines how SAML works together with SIP in alignment to SIP Identity
Solution Approach:
• Like in SIP Identity the Authentication Service adds the Identity-Info header to the SIP request after authenticating the user– In SIP Identity the Identity-Info points to the certificate of the Authentication
Service
• In SIP SAML the Identity-Info points instead to a SAML assertion conveying both the AS's certificate and user profile attributes
• The verification performed by the UAS performs (as specified for SIP Identity) is extended to cover verification of relevant SAML statements
13
SIP SAML
AuthService
INVITE
INVITE +Identity & Identity-Info
User Agent
ProxyServer
sip.remote.edusip.local.edu
User Agent
INVITE + Identity &
Identity-Info referring to SAML assertionResolve
URL toSAML assertion
14
UA-Driven Privacy Mechanism for SIP: draft-ietf-sip-ua-privacy
• Allows user agent to conceal privacy-sensitive information without the need for aid from the privacy service, as defined in RFC 3323.
• Uses recent work in the IETF to accomplish this goal: – Traversal Using Relay NAT (TURN)
– Globally Routable User Agent (UA) URIs (GRUU)
• TURN allows UA to obtain an IP address and to route traffic via the TURN relay.
• GRUU allows the UA to mint URIs on the fly. These URIs are then used in the SIP messages.
15
Challenges
• SBCs/B2BUAs break SIP Identity since the digital signature is computed over parts of the SIP message that are changed by these boxes.
• SIP Identity not widely implemented and deployed due to the way how the current peering agreements are setup. SPEERMINT working group
• Proposals for alternative SIP Identity handling have been proposed to the IETF. – Example: draft-wing-sip-identity-media
• Problems with the usage of E.164 numbers: Ownership of an E.164 number for a particular domain difficult to show.
16
Common
Policy
RFC 4745RFC 5025
Presence Authorization Rules
Geolocation
Policy
Consent
Framework
RFC 4568
Security
Descriptions
MIKEY
RFC 3830DTLS-SRTP
Identity
Example of Identity Info Consumers
Authorization
Policies
Media
Security
17
Security Description: RFC4568
• Both endpoints announce their encryption keys in SDP
• A media-level attribute "a=crypto" describes the cryptographic suite, key parameters, and session parameters for the preceding unicast media line
• Lawful interception node can pick the key from the INVITE
INVITE, Alice_Send Key
INVITE, Alice_Send Key
200 OK, Bob_Send Key
SRTP
BobBiloxliAlice
200 OK, Bob_Send Key
18
MIKEY
•Different authentication modes: – MIKEY: pre-shared key mode
– MIKEY: public key mode
– MIKEY: RSA-Diffie-Hellman mode
• Further authentication modes proposed.
• An overview can be found in draft-ietf-msec-mikey-applicability
INVITE: DHAlice, Sig(KAlice, MSG)
SRTP
BobBiloxliAlice
INVITE: DHAlice, Sig(KAlice, MSG)
200OK: DHBob, Sig(KBob, MSG)200OK: DHBob, Sig(KBob, MSG)
19
Changes in Key Management
•15+ key management proposals submitted to the IETF by end of 2006.
• draft-ietf-sip-media-security-requirements contains:– Challenging topics and scenarios for key management protocols
(e.g., retargeting and forking)
– Detailed list of requirements
– Overview and evaluation of keying mechanisms
• March 2007: Three main proposals – DTLS-SRTP
– MIKEYv2
– ZRTP
• Decision for DTLS-SRTP
20
SRTP - DTLS
• Certificate fingerprint is changed in SDP
• DTLS handshake is performed in the media channel and certificates are changed
• Encryption keys are derived from the handshake
• DTLS is multiplexed to the same ports as RTP
• Lawful interception requires Man-in-the-middle attack
BobBiloxliAlice
INVITE (fingerprint Alice)
INVITE (fingerprint Alice)
200 OK, fingerprint Bob
200 OK (fingerprint Bob)
SRTP
DTLS Handshake
21
New Challenges
• Detailed work on a specification requires design decisions to be made.
• Investigations by the 3GPP revealed problems with middleboxes along the path.
– Problems document in draft-sipping-stucker-media-path-middleboxes
– Accepted as WG item for MMUSIC
• Lawful interception requirements are confusing but might be a problem. – Solution proposal for media recording (with cooperating end point)
specified in draft-wing-sipping-srtp-key
• Problems with SIP Identity and SBCs/B2BUAs cause problems for media security as well.
22
Middleboxes in the Media Path
Functions of the middleboxes (cf. [Middleboxes]):
• gating/pinholing: block all flows that are not allocated by the MIDCOM-agent
• NAT/media relay: For a bidirectional flow AB, allocate a pair of transport addresses, one representing B towards A, one representing A towards B, and relay traffic accordingly
Focus of the presentation is on firewalling.
Alice Bob
SIP-proxyMIDCOM-agent
SIP/SDP
DTLSHandshake
Media
Filter rules,NAT bindings
DTLSHandshake
Media
SIP/SDP
Middlebox
23
Example Message Flow from [Framework]
INVITE (offer)INVITE(offer)
DTLS – Hello
DTLS – Hello
Media
DTLS – Finished
DTLS – Finished
Media
200 OK200 OK
ACKACK
24
Middlebox Impact for DTLS-SRTP
X
INVITE (offer)INVITE(offer)
DTLS – Hello
DTLS – Hello
Media
DTLS – Finished
DTLS – Finished
Media
200 OK200 OK
ACKACK
DTLS - Hello
25
Conclusion
• Different stakeholders that are part of the Internet milieu have interests that may be adverse to each other, and these parties each vie to favor their particular interests.
• These tussels are reflected during the design, re-design, configuration and also during run-time.
• Protocol design is complicated since tussels are not resolved during design time in standards organizations alone anymore.
• We are currently seeing these ongoing tussels causing protocol re-design, both for media security and for SIP Identity.
The term “tussel” was introduced in D. Clark, J. Wroclawski, K. Sollins, B. Braden: “Tussle in Cyberspace: Defining Tomorrow’s Internet”, in IEEE/ACM TRANSACTIONS ON NETWORKING, VOL. 13, NO. 3, JUNE 2005