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

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 2 Dec 2002 07:42:26 -0500

I do agree that there are meaningful threats against registrars that emerge
when a registering UAC cannot establish a direct, secure (per RFC3261, TLS)
connection to the registrar. While service disco is not the first draft to
condone architectures in which there are intermediaries in the registration
process, I do think it is a reasonable place to stage some security
considerations that focus on this case. It could be said that the RFC3261
security philosophy is "love it or leave it" - we show some architectures in
which the mechanisms we recommend will work, and the price of deviation from
these architectures is deriving your security properties from some other
mechanisms. Perhaps this leaves the ball squarely in the court of I-Ds using
different architectures.

As I'm sure we all recall, during the RFC3261 review, the IESG suggested
that over time, the normative language about S/MIME in the SIP standard
might have to be strengthened. I don't think there's anything wrong with
revisiting our security situation incrementally, as we come to understand
more vulnerabilities in the light of proposed architectures or deployments
in I-Ds that go before the SIP groups. Security considerations seem to be
one of the few places in which the IESG welcomes redundancy - if multiple
documents that consider these sorts of architectures need to have more or
less identical language to this effect, I don't think that will be a problem
(not Obviously Wrong, anyway).

So from my perspective, I support the change recommended by the Discuss.
RFC3261 is what it is - when we have the opportunity to reconsider some of
its statutes, we will undoubtedly incorporate a number of changes influenced
by drafts that have passed in the interim. Perhaps we can say that we're
issuing an IOU to revisiting registrar security in the base spec later.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, November 27, 2002 6:28 AM
> To: Adam Roach
> Cc: 'Dean Willis'; [email-masked]
> Subject: Re: [Sip] DISCUSS on Service Route Discovery
> 
> 
> inline.
> 
> Adam Roach wrote:
> >>-----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.
> 
> 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
> 
> _______________________________________________
> 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