Subject: RE: [Sip] Re: SIP and PKI

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 5 Feb 2002 20:56:24 -0600

Thanks for these very useful comments. Some notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Tuesday, February 05, 2002 1:26 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [Sip] Re: SIP and PKI
> 
[snip]
> 
> Regarding the PKI implication, 22.3.1 states that a
> mutually authenticating TLS implementation is a MUST for
> proxies. Assuming the security connection is useful, the
> certificates passed from both sides have to be verified against
> something. Thus, there has to be root certificates
> configured somewhere, and both sides must be under
> the same root. Ok, so you can use the same roots that
> you use for web servers. Fine, but this is actually
> the same as what you need to do in IPsec, isn't it?
> The typical TLS one-sided authentication is a useful
> feature, but that typically be applied UA - proxy, not
> proxy-proxy...

Yes, you should probably do the same thing (use mutual auth between proxies)
for IPSec. I think you need both one-way auth and mutual auth for a complete
PKI solution, though. We don't really specify how you might use IPSec in
bis, which is why we only talk about these auth rules in the context of TLS.
As you know, I suspect we need some kind of IPSec profile document to really
understand how IPSec will be used for SIP.

Agreed, btw, that you can use the same CA roots that you use for web servers
for proxy servers (i.e. their hostnames are the important thing).

> 
> Regarding text clarifications:
> 
> - The text says e.g. in 22.3.2.1 something about
>    verifying certificates and domain names in them.
>    Perhaps we should clarify that this indeed happens through
>    some configured root CAs -- such as those which are the
>    default in your Netscape, but some roots are needed.

Okay, we can explicitly say that this entails holding one or more CA root
certificates - that was our intention. I wonder if we should say anything
about CRLs?

> 
> - 22.3.1 sets forth requirements for UAs to verify
>    certificates. Why are these a SHOULD, not a MUST?

I read in 22.3.1 that certificate verification is a MUST for TLS, and a
SHOULD/MAY or S/MIME. The SHOULD/MAY for S/MIME reflects that we expect
self-signed "leap of faith" stuff to be more common than the use of root
certificates.

Btw, I will remember to add something somewhere about configuration as one
way of learning about remote certificates for S/MIME.

> 
> - And why aren't there any requirements for proxies
>    to do the verification?

It's an oversight; frankly, I just assumed it would be understood. We can
spell that out explicitly in bis if it seems especially misleading. We show
this behavior in 22.3.2.2, anyway.

> 
> - In 22.3.2.2 there's the following text that describes
>    how to talk TLS between two proxies: "... noting the domain
>    name that appears in the certificate for comparison with
>    the headers of SIP messages." Maybe it is obvious, but
>    I'm not sure which headers this refers to. Certainly not
>    the From, since this was the transitive case. The Via,
>    then? Any DNS operations in between?
> 
> - Wouldn't it be sufficient to verify *either* the From
>    field against the TLS certs, or the latest via/source
>    address? Then the INVITE comes from a known source in
>    any case.

Well, 22.3.2.2 assumes a sort of network in which every administrative
domain that supports SIP has a proxy (acting as a registrar/local
outbound/inbound proxy), and every administrative domain's proxy can reach
every other administrative domain's proxy - although they don't necessarily
have a pre-existing trust relationship. We don't talk too much about these
underlying assumptions because this is, after all, just an example of how
trust relationships could be established. In any event, for this
architecture the From field of each request contains a domain which will
correspond to the hostname of the proxy server from which a request
originates - which should also correspond to the proxy's certificate. The
term 'correspond' here is intentionally a little loose - the proxy's
hostname might be 'sip.atlanta.com', whereas the From field of a request
might be 'sip:[email-masked]'.

The correspondence of the proxy's domainname and certificate is initially
discussed in the first paragraph of 22.3.2.1. The fact that requests coming
from your administrative domain should probably have From fields
corresponding to your domainname is discussed in 22.3.2.2 - again, this
example architecture doesn't take into account any sort of transit carrier
that requests might need to go through. The topmost Via header would
probably also help the remote proxy to confirm the identity of the local
proxy - but it wouldn't, however, help the local proxy understand the remote
proxy's position; the local proxy just makes sure that the certificates
corresponds to the Request-URI of the request it has sent.

> 
> - 5th paragraph in 22.3.2.2 ends abruptly. Something missing?

It doesn't end abruptly in the .pdf version, just the .txt version. I've
learned that LaTeX really hates single ticks (`) on a line when it is
rendering txt, in this case it's tripping on: `biloxi.com'. We'll fix that.

> 
> Jari
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Jari Arkko" <[email-masked]>
Date: Wed, 13 Feb 2002 17:41:17 +0200

> certificates - that was our intention. I wonder if we should say anything

Don't say anything about CRLs. Or at the most, MAY access ... CRLs
don't work well if you happened to have a very large user base. There
are also alternative schemes such as OCSP.

> self-signed "leap of faith" stuff to be more common than the use of root

Yes, but we MUST still verify the certs, even if they are verified against
our leap-of-faith learned individual "root" certs...

> corresponds to the Request-URI of the request it has sent.

Ok

Jari