Subject: [Sip] DISCUSS on Service Route Discovery

From: Dean Willis <[email-masked]>
Date: 25 Nov 2002 15:45:53 -0600

The cool new ID tracker:

https://datatracker.ietf.org/public/pidtracker.cgi

shows that we have an IESG "Discuss" on the Service Route Discovery
draft:

http://www.ietf.org/internet-drafts/draft-ietf-sip-scvrtdisco-02.txt

which is currently in the "IESG Evaluation" phase of IETF Last Call.

The specific issues raised are:

---------------
The Security Considerations section is confusing, and (I think) wrong.

The first paragraph speaks of proxies modifying things.  This is indeed 
a threat.  But the end of that paragraph and the next speak of using 
transport security between proxies.  That does nothing against this 
threat -- the problem occurs from misbehavior by the authorized proxy.  
Transport security protects against MITM attacks, not nasty endpoints.

The note at the end of the second paragrap, suggesting S/MIME, is the 
correct answer against this threat.  Transport-level security might be 
useful against other threats.

I suspect that fixing the first sentence of Section 7 to speak of MITMs 
instead of proxies will clear up the confusion; the issue of 
misbehaving proxies can be described briefly in the second paragraph.

I'm also concerned that there's no mandatory-to-implement specified (or 
is S/MIME support required of Registrars elsewhere?).  If not, there 
should be some text somewhere mandating implementation of it, though 
(of course) not necessarily use; the current "SHOULD" language is 
sufficient.
---------------

The first problem is that we have intermingled MITM and misbehaving
proxies. This can be easily rectified, I think, as suggested in the 
DISCUSS.

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.

What do you think?

-- 
Dean Willis <[email-masked]>
_______________________________________________
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: "George Foti (LMC)" <[email-masked]>
Date: Wed, 27 Nov 2002 11:14:32 -0500

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]]
> >>
> > 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
>