Subject: [Simple] Re: Discuss on SIMPLE doc

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 23 Jan 2003 08:42:32 -0500

In message <[email-masked]>, Jonathan Rosenberg writes:
>This note is in response to comments raised by Steve Bellovin during the 
>IESG review of the simple specs.
>
>Steve, thanks for the comments. Responses inline.
>
> > ------- Forwarded Message
> >
> > From: "Steven M. Bellovin" <[email-masked]>
> > To: IESG Secretary <[email-masked]>
> > Cc: Internet Engineering Steering Group <[email-masked]>
> > Subject: Re: Evaluation: draft-ietf-simple-winfo-package - A Session 
>Initiation Protocol (SIP)Event Template-Package for Watcher Information 
>to Proposed Standard
> >
> > draft-ietf-simple-presence-09.txt:
> > 	6.3 should say "some other document will define
> > 	a filter language".  The current language is too vague.  (This
> > 	can be fixed with an RFC editor's note.)
>
>It looks like I need to rev these for other comments too. So, I changed
>to text to be more specific. Here is how that paragraph reads:
>
>One type of body that can be included in a SUBSCRIBE request is a
>filter document. These filters request that only certain presence
>events generate notifications, or would ask for a restriction on the
>set of data returned in {\NOTIFY} requests. For example, a presence
>filter might specify that the notifications should only be generated
>when the status of the user's instant inbox \citenonnorm{rfc2778}
>changes. It might also say that the content of these notifications
>should only contain the status of the instant inbox. Filter documents
>are not specified in this document, and at the time of writing, are
>expected to be the subject of future standardization activity.

Looks good.
>
> >
> > 	6.6.1 -- which authentication methods are mandatory to
> > 	implement?  Ditto 9.2 and 9.4.  Also see 6.2 in
> > 	draft-ietf-simple-winfo-package-04.txt
>
>RFC 3261 mandates digest for authentication purposes. I've added a
>sentence to 6.6.1 which states:
>
>Note that digest is mandatory to implement, as
>specified in RFC 3261.
>
>Regarding 9.2 (which discusses autehntication and message integrity) and
>9.4 (which discusses replay), digest can address the authentication and
>replay issues (its not perfect of course). Do you feel it needs to state
>baseline mechanisms beyond those specified in RFC 3261? It was always my
>assumption that it did not, which is why there are no normative
>statements about security mechanisms.

I confess that I don't have 3261 memorized...  You're referring to HTTP 
Digest, as described in Section 22 of 3261, as well as 26.3.2.1 as 
called out in this draft?  My problem with 6.6.1 is with the language 
"any of the mechanisms".  HTTP Digest is adequate for authentication, 
but that's not what this says; it says "3261 defines several; pick one".
Your suggested change resolves the problem.

For 9.2 and 9.4, the problem is permissive wording.  For example, 9.2 
says "IPs authentication and message integrity features can be used."
It wasn't clear to me that you were mandating those mechanisms.  
Similarly, 9.4 says "SIP S/MIME can provide" and "HTTP digest 
authentication MAY be used".  What is mandatory to implement here?  SIP 
is a sufficiently rich protocol that it isn't always clear which 
elements of it apply to which profiles or instantiations -- I'm asking 
for just a bit more prescriptive language in the spec.
>
>
> >
> > 	It appears to be possible to probe the name space to see what
> > 	user names are valid.  Is this a concern?
>
>It doesn't seem any more of an issue than it would be in any other
>application protocol. I don't recall it being raised as a concern
>specifically.
>
>Note that its not specific to presence. The presence behavior directly
>inherits from baseline sip. In baseline SIP you'd get a 404 response if
>the user is not valid in that domain.
>
>Thanks,
>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
>
>
>
>

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Jan 2003 15:16:54 -0500

Thanks for the response. Comments inline.

Steven M. Bellovin wrote:

> I confess that I don't have 3261 memorized...

What? 269 pages and you haven't memorized it?? ;)

>  You're referring to HTTP 
> called out in this draft? 

Yes.

> My problem with 6.6.1 is with the language 

OK.

> It wasn't clear to me that you were mandating those mechanisms.  

No. The intent was that RFC3261 provides such mechanisms, and it also 
states the implementation strength of them.

That said, we do introduce a new element here - a presence agent, which 
is a UA by SIP definitions. However, I think we may need to introduce 
additional security requirements for implementors of a PA so that 
presentities and watchers can get security services. I would imagine 
that all PA MUST implement TLS (and consequently sips), and MUST support 
digest (already mandated by rfc3261).

So, I changed the wording in 9.2 to say:

> RFC 3261 provides many mechanisms to provide these features. In order
> for the PA to authenticate the watcher, it MAY use HTTP Digest
> (Section 22 of RFC 3261). As a result, all watchers MUST support HTTP
> Digest. This is a redundant requirement, however, since all SIP user
> agents are mandated to support it by RFC 3261. To provide authenticity
> and integrity services, a watcher MAY use the SIPS scheme when
> subscribing to the presentity. To support this, all PA MUST support
> TLS and SIPS as if they were a proxy (see Section 26.3.1 of RFC 3261).
> 
> Furthermore, SMIME MAY be used for integrity and authenticity of
> SUBSCRIBE and NOTIFY requests. This is described in Section 23 of RFC
> 3261. 

is this better?

> authentication MAY be used".  What is mandatory to implement here?  

Digest, as it is in SIP. S/MIME is a MAY. I've clarified that, so that 
the text now reads:

> SIP S/MIME can provide message integrity and authentication over SIP
> request bodies. Watchers and PAs MAY implement S/MIME signatures
> to prevent these replay
> attacks. When it is used for that purpose, the presence document
> carried in the NOTIFY request MUST contain a timestamp. In the case of
> PIDF, this is accomplished using the timestamp element, as described
> in Section 6 of
> \citenorm{draft-ietf-impp-cpim-pidf}. Tuples whose timestamp is older
> than the timestamp of the most recently received presence document
> SHOULD be considered stale, and discarded.
> 
> Finally, HTTP digest authentication (which MUST be implemented by
> watchers and PAs) MAY be used to prevent replay attacks, when there is
> a shared secret between the PA and the watcher. In such a case, the
> watcher can challenge the NOTIFY requests with the auth-int quality of
> protection.

Similarly, in 6.2 of the watcherinfo spec, I changed the wording to read:

> One way in which this information can be revealed is eavesdropping. An
> attacker can observe watcherinfo notifications, and learn this
> information. To prevent that, watchers MAY use the SIPS scheme when
> subscribing to a watcherinfo resource. Notifiers for watcherinfo MUST
> support TLS and SIPS as if they were a proxy (see Section 26.3.1 of
> RFC 3261).
> 
> SIP encryption, using S/MIME, MAY be used end-to-end for the
> transmission of both SUBSCRIBE and NOTIFY requests.
> 
> Another way in which this information can be revealed is through
> spoofed subscriptions. These attacks can be prevented by
> authenticating and authorizing all watcherinfo subscriptions. In order
> for the notifier to authenticate the subscriber, it MAY use HTTP
> Digest (Section 22 of RFC 3261). As a result, all watchers MUST
> support HTTP Digest. This is a redundant requirement, however, since
> all SIP user agents are mandated to support it by RFC 3261.

Are these improved wordings and requirements OK?

-Jonathan R.