This document discusses the integration of SIP (Session Initiation Protocol) and DANE (DNS-Based Authentication of Named Entities) to enhance security by using DNSSEC for certificate validation. It outlines the approach for utilizing TLS (Transport Layer Security) certificates, DANE constraints, and the importance of secure delegation in DNS lookups for SIP communications. The author, Olle E. Johansson, emphasizes the need for proper validation to ensure secure connections between SIP clients and servers.

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
identifier

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
identifier

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