• Save
SIPCORE - presentation of SIP and DANE (IETF #89)
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


SIPCORE - presentation of SIP and DANE (IETF #89)

Uploaded on

A presentation of how DANE may apply to the Session Initiation Protocol (SIP). Written for the SIPcore meeting at IETF #89 in London, 2014

A presentation of how DANE may apply to the Session Initiation Protocol (SIP). Written for the SIPcore meeting at IETF #89 in London, 2014

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 23

http://t.co 18
https://www.facebook.com 2
http://flipboard.com 1
https://m.facebook.com&_=1393943213550 HTTP 1
http://plus.url.google.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. SIP and DNS-sec based TLS setup (DANE) random thoughts by oej@edvina.net
 Olle E. Johansson ! V 3.14 - 2014-02-27 IETF 89, London, March 2014 1
  • 2. Today’s question • SIP & DANE Do we want to add this work to our charter? 2 Olle E. Johansson
  • 3. SIP & TLS • SIP uri target domain is verified against SubjectAltName uri records • if no SAN uri records, SAN DNS records • If no SAN records, CN • But no CN check if there are SAN records! RFC 5922 SIP & DANE 3 Olle E. Johansson
  • 4. Dependencies DNS TLS SIP SIP domain certificates DNSsec DANE SIP + DANE To trust DANE
 you need to trust DNSsec SIP & DANE 4
  • 5. Dane simplified DNS zone
 signed, trusted TLS server
 stockholm.example.com Certificate
 identifier TLS client SIP & DANE 5
  • 6. Questions TLS server
 stockholm.example.com Is the certificate
 signer (CA) the right one? Do I trust this certificate? Am I talking with the 
 right server? TLS client SIP & DANE 6
  • 7. DANE simplified TLS server
 My service use this CA DNS zone
 signed, trusted stockholm.example.com My service use this certificate TLS client SIP & DANE My service use the private
 key that match this public key 7 Certificate
  • 8. Dane summary • • • SIP & DANE Can publish constraints • • This CA is the only one accepted This certificate is the only one accepted Can publish root of private CA • This CA cert is the one used to sign my server certificates Can publish certificates In all cases, a full cert or the public key can be published - or fingerprints of these. 8 Olle E. Johansson
  • 9. TLSA selector and matching Selector • 0 - Full certificate included in TLSA • 1 - Public key included in TLSA Matching • 0 = Exact match • 1 = the data is SHA-256 hash of content • 2 = the data is SHA-512 hash of content SIP & DANE 9 Olle E. Johansson
  • 10. TLSA records • Usage 0: CA constraint. Certificate or public key of CA • Usage 1: Certificate constraint. Certificate or public key of cert signed by CA. • Usage 2. Certificate or public key of cert serving as trust anchor for the cert given by the server (”private CA”) • Usage 3: A certificate or public key that matches the cert given by the server (No PKIX check) SIP & DANE 10 Olle E. Johansson
  • 11. DANE simplified DNS zone
 signed, trusted TLS server
 stockholm.example.com 2.Verify the TLS server cert
 in handshake with TLSA record. TLS client SIP & DANE 1. Check the TLSA record for service 11 Certificate
  • 12. The DANE promise • If you trust the DNS (using DNSsec)
 then we can use that instead of the certificate store to check server identity and authorisation. SIP & DANE 12 Olle E. Johansson
  • 13. Back to SIP SIP & DANE 13
  • 14. SIP DOMAIN CERTS • Connect a SIP URI domain part with a certificate • Mix server identification with domain authorisation • Only domains in the certificates • New certificate every time we add a domain or subdomain • No wildcard certs SIP & DANE 14 Olle E. Johansson
  • 15. What about SNI • Many certificates on one TLS server and IP. • No support for DNS names • ONLY host names. SIP & DANE 15 Olle E. Johansson
  • 16. SIP sip:alice@example.com example.com NAPTR We just trust that we’ve hit
 the right server if the cert
 contains the domain. example.net SRV host sip02.example.org Cert with “example.com” SIP & DANE 16 Olle E. Johansson
  • 17. DANE Secure delegation sip:alice@example.com if the DNS queries for NAPTR and SRV records was verified and protected with DNSsec, we have a secure delegation from example.com to sip02.example.org Protected by DNSsec example.com NAPTR example.net SRV host sip02.example.org Cert with “sip02.example.org” SIP & DANE 17 Olle E. Johansson
  • 18. Not fully secure is insecure • If the NAPTR was DNSsec protected but not the SRV, we have no secure delegation. • If there’s no DNSsec in either NAPTR nor SRV we’re insecure too. • The SIP Uri to TLS certificate matching in RFC 5922 applies in this case SIP & DANE 18 Olle E. Johansson
  • 19. If we have a secure delegation • Check for TLSA record for the srv host name and port • _5068._udp.sip02.example.org • If no TLSA record is found, then DANE doesn’t apply - proceed according to RFC 5922 • If TLSA record exists, continue to the next slide SIP & DANE 19 Olle E. Johansson
  • 20. Our identifiers • The SIP domain in the request URI • Used in insecure delegation • The SRV FQDN from SRV lookup of the domain (protected with DNSsec) • Used in secure delegation as well as with TLSA record verification SIP & DANE 20 Olle E. Johansson
  • 21. Validation • With TLSA usage 0 and 1, use these constraints then verify cert as before • With TLSA usage 2 and 3, use the information to validate cert • • SIP & DANE If either TLSA validation fails, connection should fail. With usage 0 and 1, after TLSA validation normal PKIX validation happens.
 21 Olle E. Johansson
  • 22. Sideways jumps • When a NAPTR or SRV record points to a name in another domain, the client needs to make sure that the new domain is validated in DNSsec as well. • If not, delegation is insecure SIP & DANE 22 Olle E. Johansson
  • 23. SIP Fallback logic • If there’s no secure delegation, use RFC 5922, if that fails go to next SRV server in the list • When out of SRV servers, TLS connection has failed. SIP & DANE 23 Olle E. Johansson
  • 24. Compatibility with nonSRV clients • Fallback to RFC 5922 • Since dane-srv-02 requires TLS SNI this will be sorted out by the server. • SRV/DANE compatible UAs will require cert for SRV host name • Non SRV/DANE UAs will require cert with SIP uri target domain SIP & DANE 24 Olle E. Johansson
  • 25. If no SNI support is available • Cert with • CommonName = hostname • SubjectAltName = SIP domain SIP & DANE 25 Olle E. Johansson
  • 26. SIP connection reuse • RFC 5923 use TLS cert content to add aliases to a connection. • With DANE, the cert will include only the hostname • SIP/DANE will have to add aliases as they are verified using DNSsec • If a domain share a SRV hostname and the trust chain is verified between domain and SRV, the existing connection to the SRV host may be used for this domain too (and alias added to the alias table)
 SIP & DANE 26 Olle E. Johansson
  • 27. Verification of client certificates in RFC 5923 • Connection reuse requires a SIP server using RFC 5923 to request a client certificate • Which DNS name do we use to look up TLSA records and verify the client? Can this be done? SIP & DANE 27 Olle E. Johansson
  • 28. Not to worry about now • SIP identity • SIMPLE • SIPS: uri’s For these use cases,
 there’s no difference compared with other TLS usage in SIP. SIP & DANE 28 Olle E. Johansson
  • 29. Reading material RFC 5922 SIP Domain Certificates RFC 6698 draft-ietf-dane-srv DNS based authentication of named entities (DANE) DANE and SRV/MX records draft-ietf-dane-smime DANE and SMIME identities draft-ogud-dane-vocabulary DANE vocabulary for application usages RFC 5923 Connection Reuse in SIP draft-johansson-dispatch-dane-sip-01 The draft on SIP and DANE SIP & DANE 29 Olle E. Johansson