Subject: RE: [Sip] DISCUSS on Service Route Discovery

From: Adam Roach <[email-masked]>
Date: Mon, 25 Nov 2002 20:06:11 -0600

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> 
> The second concern seems to be more interesting. Is it reasonable to
> mandate that registrars implementing the Service-Route header 
> field also
> MUST implement S/MIME? This doesn't say they have to USE it, just that
> they must IMPLEMENT it. 
> 
> My personal feeling is that implementing this in a registrar is fairly
> straightforward, and even the key management is easy, so it "does no
> harm" to include as a MUST.

I'm inclined to agree; first, though, I'd like to understand the threat
posed by a registrar that doesn't/can't use S/MIME versus one that
can. Not in the general context of registering, of course -- only
in the context of the extra functionality introduced by srvrtdisco.

It's not obvious to me that this point is addressing an issue raised
by *this* draft, versus a general issue with SIP -- and it would
be Obviously Wrong (tm) to fix problems in the base spec in every
other document that mentions it, as opposed to just recording it
as a bug and fixing it next go round.

/a
_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 27 Nov 2002 09:28:07 -0500

inline.

> as a bug and fixing it next go round.

I agree. I don't believe the threats specific to service route are worse 
than the general threats imposed through impersonating a registrar, 
which are explicitly called out in section 26.1.2 of bis. Indeed, the 
insertion of a fake 301 response to a REGISTER request is much more 
damaging than a fake service route, I believe.

So, if we think that S/MIME is a MUST to protect service route, then its 
also a MUST for rfc 3261.

I suppose the counter-argument might be this. Bis more or less assumes 
that there is the possibility of a direct connection between the client 
and registrar, as it talks about using TLS to secure registrations 
(Section 26.3.2.1). Almost by definition, that approach doesn't work for 
the problem space of service route, because of the existence of proxies 
between the UA and the registrar, not a common case. Thus, this draft is 
addressing a specific architecture where the normal bis security 
recommendations don't apply, and thus a different recommendation is needed.

I'm not entirely sure I believe this counter-argument....

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com