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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 28 Nov 2002 16:46:12 -0000

I would prefer to keep this requirement at the same level as RFC 3261.

Failing that I would have to insist on an applicability statement that said that the MUST applied only if other security mechanisms were not available. 

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

> -----Original Message-----
> From: George Foti (LMC) [mailto:[email-masked]]
> Sent: 27 November 2002 16:15
> To: 'Jonathan Rosenberg'; Adam Roach
> Cc: 'Dean Willis'; [email-masked]
> Subject: RE: [Sip] DISCUSS on Service Route Discovery
> 
> 
> I have to agree with Jonathan & Adam.
> Making this is MUST just to support service route *ONLY* is 
> inconistent with RFC 3261.
> There are numerous things in RFC 3216 for which the same 
> argument can apply but it does not.
> Lets be consistent.
> Rgds/gf
> 
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [mailto:[email-masked]]
> > Sent: Wednesday, November 27, 2002 9: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
> 
_______________________________________________
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: Chris Martin <[email-masked]>
Date: Wed, 27 Nov 2002 18:47:26 -0600