Subject: [Sip] high level sip-identity comments

From: Michael Thomas <[email-masked]>
Date: Mon, 21 Mar 2005 12:43:51 -0800

I did a slightly better cursory reading of sip-identity
and have some questions.

1) The draft seems to conflate authentication and 
   authorization. That is, just because I have a certificate
   for something in a given domain doesn't mean that I'm
   authorized to speak on behalf of the domain. How is
   the receiver supposed to know if a given cert is authorized
   to sign, say, outgoing SIP messages?

2) There is reference to fetching the cert via the 
   IDENITY-INFO headers, but this seems to be really
   underspecified. What is the format of the request
   URI? Can it take GET/POST requests? Can GET/POST 
   send parameters? What is the format of the return
   value from the query? Since this draft is intended
   for inter-domain use where there can't be an expectation
   of a prior introduction, I don't think this can be
   handwaved.

3) I must have missed it, but I didn't see any discussion
   of header and body canonicalization. How is the hash
   that goes into the RSA signature constructed? Which headers?
   What is the order they are fed? Does whitespace count? 
   What about volatile headers like Via... how does the
   receiver know which headers to feed into the hash? 
   Likewise, are their extant weirdisms like in email that
   proxies, etc, munge headers and/or bodies? If so, then
   what?

4) As Jonathan also pointed out, there's no way to express
   whether a domain has a policy of "we sign everything".
   Unless that's available, you have a trivial bid down
   attack by simply not adding an Identity header to your
   SIP method of choice.

I guess that's enough for now.

		Mike
_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Mon, 21 Mar 2005 20:39:21 -0800

Thanks for the read - few inline...

>    to sign, say, outgoing SIP messages?

It seems that attributes about what a certificate can be used for are widely
ignored so we have just gone with the idea that if you have the private key,
then the assumptions is you are authorized to sign. The expectation that
these attributes are checked when they are not seemed like more of a
security risk than the alternative. Note the domain could choose separate
domains for separate services - for example SIP could be sip.example.com
while web was www.example.com

>    of a prior introduction, I don't think this can be

agreed - got the message loud and clear from a few people. we will fix the
text to clear up the confusion about how this can be done.

>    proxies, etc, munge headers and/or bodies? If so, then
 
I think we tried to be very clear in what we hashed such that for the most
part no canonicalization is necessary - that is why we specified specific
sub fields from the BNF. Some things like the date we did have to provide
some additional canonicalization text for. In the body, everything is bit
for bit copied including.

>    attack by simply not adding an Identity header to your

Yep - agree. I thought we discussed this is the draft but perhaps I just
wish we did :-) I don't see any solution to this other than for enough
people to implement this that at some point in time it is practical to
switch to requiring it. I know ideas involved using DNS to find out have
been bounced around and perhaps future work could deal with that. They
proposal I have heard so far mostly seem to rely on DNSSec.

> I guess that's enough for now.

Thanks, Cullen

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Mar 2005 08:32:27 -0800

> while web was www.example.com

Name space separation _can_ work, but has to be completely
specified: as the receiver, I have no idea whether sip.example.com
is authorized to sign for a domain anymore than 
party.on.d00d.example.com is legitimate. Since this needs to
work in the case where there is no established relationship
between the two parties, you'd need to partition the namespace
as part of the standard itself.

That said, I don't really like carving off portions of
the namespace unless you really have no alternative. This
is especially true for certs since there isn't an equivalent
of IANA saying that the namespace prefix of _xyz is reserved (at
least that I know of). The other part is that this just
serves to propagate the conflation of auth and authz. In IIM,
we are very explicit that the purpose of the record coming
back from the KRS is an _authorization_ record, and that the
authorization is bounded for particular services (eg SMTP). 
Explicit authorization, either in the cert itself, or in a
authz service (ala KRS) would be a lot safer.

> text to clear up the confusion about how this can be done.

The other thing that confused me was whether it was assumed
that I'd need to fetch the cert in _all_ cases (modulo caching).
That is, if I'm a signer do I need to put this cert-fetch service
up so that others can get my certs? It's possible I missed
it, but I didn't see a way to ship the cert in the method 
itself. If it is the case that you'd be expected to get it from
this server, you ought to consider whether the payload the
server returns also has authz information.

Also: at the point that you're fetching something from a
home cert server, I'm not sure what the PKI aspects of are buying
you other than the general hassle of having to get those
certs, etc, etc. In IIM, we could have said that the identities
were X.509 ones but it seemed like vast overkill, not to 
mention that it's very confusing. Which is why we decided to
support identities that can be auto-generated by using the
uniqueness properties of the public key itself.

> for bit copied including.

When I say canonicalization, it doesn't have to mean that
the bits need to be altered or massaged or anything like
that, only how and what is marshalled through the one-way
hash. Experience here shows that it is impossible to be
too explicit: it's where interoperability usually goes to
hell in a handbasket. For example, when you say add a
header, does that include or not include syntactic 
whitespace? What about things that might reformat headers?
What about continuation headers? What about header reordering?
(in mail, this is just a fact of life, with SIP it may be
present in some proxies/UA's and you don't realize it). 

Also: it seems to me that just having the signature in 
the sig line isn't sufficient. In IIM, we have a version,
a time to live, and several other fields as well. I'm 
also uncomfortable with having an explicit enumeration
of which headers are signed in the spec without a 
mechanism for adding new protected headers... and if the
mechanism is issuing a new RFC, that's losage.

And what about multiple signatures? If a message passes
through multiple domains, what does that mean? What does
a receiver do if it finds multiple signatures? Is there
the possibility that supposedly transparent proxies will
modify any of the headers and/or body parts (in mail, the
obvious example are mailing lists). 

> proposal I have heard so far mostly seem to rely on DNSSec.

It could rely on either DNSsec or PKI ala TLS server certs;
there are tradeoffs for either approach. It could be both
for that matter -- or neither depending on risks. 
The same thing goes for your cert server for that matter: 
when I'm fetching the cert, how do I know that I'm not being
redirected to a bogus server? This needs to be addressed at 
the very least in your security considerations.

		Mike

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Mar 2005 09:48:52 -0500

> proposal I have heard so far mostly seem to rely on DNSSec.

The identity is something the caller (or his agent) provides in hopes 
that it will result in his getting better treatment by the recipient.

The bid-down should just mean that the caller doesn't get that better 
treatment. If I do it to myself, then I get what I deserve. If I want 
the identity but some interloper removes it, then I should eventually 
realize something is happening and move to get the problem solved.

On the recipient side, once identity starts to be deployed, I will 
perhaps encourage my friends to use a provider who supplies it. And at 
least I will rapidly learn which ones have it. For friends that don't, I 
will have to always be a bit suspicious if I am talking to them or a fake.

I suppose the big issue is with the presence or absence of identity in 
calls from strangers. I think the best we can hope for in transition is 
that the UI provides good indication of the reliability of caller 
identity. Some mark (like the little lock in browsers for TLS) would 
help. Or your UA could have a feature to reject calls without identity.

So I don't see this as a big or unexpected problem.

	Paul