Subject: [tram] STUNBIS: TLS verification

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 26 Jul 2016 09:02:18 +0200

Hi!

The part about TLS verification is not clearly written in the draft.

Consider the following examples:

1) Configured STUN server name: “sollentuna.example.com” 
    Server redirects to “stockholm.example.com”  - which name needs to be in the cert?

2) Configured STUN server name: “orust.example.com”
    DNS SRV leads to “arlanda.example.net” as first selection
    - which name needs to be in the cert?

3) Configured STUN server name: “bromma.example.com”
     Certficate has “*.example.com” - are wildcards approved? (SIP doesn’t approve)

4) Configured STUN server name: “sigtuna.example.com”
    Cert has “sigtuna.example.com” in subject - but “sigtuna.example.net” in SAN
    Is this approved? (In SIP it would not be)

We need to be clear on verification procedures, especially in the case of DNS SRV and STUN redirects.

RFC 6125 is a better reference here than the old HTTP rfc.

/O

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Jul 2016 10:22:32 +0200

I agree that 6125 is best here.  Simple answers:

>     Server redirects to “stockholm.example.com”  - which name needs to be in the cert?

If the redirect is authenticated, then it can be stockholm

>     - which name needs to be in the cert?

orust - we don't trust the DNS

>      Certficate has “*.example.com” - are wildcards approved? (SIP doesn’t approve)

*.example.com should be OK

>     Is this approved? (In SIP it would not be)

no - I don't see how a complete name mismatch could ever be acceptable

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 26 Jul 2016 10:33:09 +0200

> On 26 Jul 2016, at 10:22, Martin Thomson <[email-masked]> wrote:
> 
“can be”  :-)
In SIP we always compare with the original URI and avoid redirections.
In that case it’s “sollentuna”. This is clearly something that needs to be documented.
In 6125 lingo, the server name “sollentuna.example.com” is the reference identifier.
What you propose is that a STUN redirect change the reference identifier
which I’m fine with. The first STUN server needs a cert for sollentuna.example.com
so we clearly trust that server. The redirect goes to stockholm and the
cert in that server needs to verify for Stockholm.
I think that case needs to be clear in stunbis.

> orust - we don't trust the DNS
Ok, let’s take the DNSsec case later. Marc and I had a draft on that earlier that we
need to revive after this is done.
> *.example.com should be OK
Following 6.4.3 in 6125 then
> no - I don't see how a complete name mismatch could ever be acceptable
Right, if there are SAN, the Subject CNAMe must be ignored. 

/O
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Jul 2016 11:06:56 +0200

> In SIP we always compare with the original URI and avoid redirections.

Redirects are a form of delegation that - if authenticated - can mean
that you change the reference identity.  That's the way that 3xx works
in HTTP for example.  But you could - as with SIP - decide that the
reference identity does not change (see Alt-Svc in HTTP for an
analogy).

Thus, you need to pick one.  But you do need to pick one.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 26 Jul 2016 11:24:38 +0200

> On 26 Jul 2016, at 11:06, Martin Thomson <[email-masked]> wrote:
> 
Exactly - and it needs to be documented.

/O