peeking into ietf security standardization · early approaches 6 rfc 3261 • s/mime: provides a...
TRANSCRIPT
1
Peeking into IETF Security Standardization
3rd ETSI Security Workshop, Jan. 2008
Hannes Tschofenig
The IETF110+ working groups in 8 areasSecurity work in the Security Area and also in other working groups.
Applications Area
General Area
RAI Area
InternetArea
RoutingArea
SecurityArea
TransportArea
SIP SIPPING AVT GEOPRIV
RAI
SIMPLEMMUSIC
…
O & M Area
2
Identity in SIP
SIP IdentityRFC 4474
RFC 3261 S/MIME
RFC 3325P-Asserted-Identity
SIP SAML
SIP CERT
RFC 3261ConnectedIdentity
RFC 3323SIP Privacy
UA-Driven Privacy Mechanism for SIP
3
Examples of Identity Info Consumers
Common PolicyRFC 4745
RFC 5025 Presence Authorization Rules
GeolocationPolicy
ConsentFramework
RFC 4568SecurityDescriptions
MIKEYRFC 3830
DTLS-SRTP
Identity
AuthorizationPolicies
MediaSecurity
4
SIP in a Nutshell
SIP / RTP / RTCP
Proxy BSIP/SDP
Alice
Proxy A
SIP/SDP SIP/SDP
BobSession 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.
5
Early Approaches
6
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
RFC 3323: Privacy in SIP
7
Guidelines for providing maximal user-provided privacy• Using anonymous values for display names and URIs in From header and
user part of the Contact headerConcept 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
RFC 4474: An overview of operation
8
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
Authentication Service within local SIP proxy
AuthenticationService ofhome.com
SIPcloud
INVITE sip:[email protected] SIP/2.0From: sip:[email protected]: ….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.0From: sip:[email protected]: Fri, 1 Jun 2007 13:29:00 GMTIdentity: <signed hash of sipfrag>Identity-Info: https://home.com/cerContent-Type: application/SDPAdds also
a referenceto home.comcertificate tothe request
Checks thevalue of Dateheader or addssuch if missing https://home.com/cer
storing 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 answerConnected 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-certs
11
Assumptions• client certificates will be self-signed and users will have many devices per
identitySolution: 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
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) SUBSCRIBE
sip:[email protected]: certificate
NOTIFYEvent: certificate(Bob’s certificate)
AuthenticationService
NOTIFY+IdentityEvent: certificate(Bob’s certificate)
SUBSCRIBEsip:[email protected]: certificate
ewing.com
12
SIP SAML: draft-ietf-sip-saml
Based on requirements and scenarios defined in RFC 4484Defines 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 IdentitySolution 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
14
AuthService
INVITE
INVITE +Identity & Identity-Info
sip.local.edu sip.remote.edu
ProxyServer
INVITE + Identity & Identity-Info referring
to SAML assertionResolveURL toSAML assertion
User AgentUser Agent
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 there is almost no deployment 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
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 KeyINVITE, Alice_Send Key
200 OK, Bob_Send Key
SRTP
BobBiloxliAlice
200 OK, Bob_Send Key
17
MIKEY
INVITE: DHAlice, Sig(KAlice, MSG)
SRTP
BobBiloxliAlice
INVITE: DHAlice, Sig(KAlice, MSG)
200OK: DHBob, Sig(KBob, MSG)200OK: DHBob, Sig(KBob, MSG)
•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
18
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
19
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 Bob200 OK (fingerprint Bob)
SRTP
DTLS Handshake
20
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.
21
Middleboxes in the Media Path
22
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 A B, allocate a pair
of transport addresses, one representing B towards A, onerepresenting 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
Example Message Flow from [Framework]
23
Middlebox Impact for DTLS-SRTP
X
24
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 200525