Subject: [Simple] Comment on draft-ietf-simple-data-req-00

From: "Vesa Torvinen (LMF)" <[email-masked]>
Date: Thu, 24 Oct 2002 08:11:59 +0200

Hi, 

I have been wondering if the presence authorization policy 
should include a fourth piece (in addition to acceptance, 
notification and content policies), i.e. the security policy. 
As an end-user, I could imagine setting an authorizatin 
policy saying that the confidentiality of all notifications 
should be protected, for example. The other filterin criteria, 
notification frequencies and the contents of notifications 
could still be valid, however, the notification would not be 
delivered to the watcher if encryption was not available. 

I can also imagine a scenario in which my Presence Agent has 
no trust relationship with a particular watcher, and can not 
authenticate the watcher. In this case, I as an end-user might 
be willing to set this trust relationship, e.g. by defining a 
subscription specific HTTP Digest password for that watcher, 
and by distributing the password to the watcher using some 
other communication channel (e.g. phone or face-to-face 
contact). 

Maybe the security policy could look something like this: 

---------

Security Policy: The component of presence authorization policy 
that determines the minimum security requirements for subscriptions 
and notifications. 

---------

Security Policy Requirements 

REQ 1: It MUST be possible for the user to determine the minimum 
security functions to be used with subscriptions and notifications. 

REQ 2: It SHOULD be possible for the user to bind the watcher 
authorization to a particular authentication function and credential. 

-----------

But maybe you have already discussed this issue and decided 
something else? (Checked the mail archive but did not find 
anything...) 

Vesa

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 24 Oct 2002 17:37:07 -0700

> other communication channel (e.g. phone or face-to-face

self-signed cert?

thx,
-r

> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 25 Oct 2002 03:42:46 -0400

I think that this is generally a good idea. Some comments below.

> delivered to the watcher if encryption was not available. 

I agree with this requirement, but think its really two additional 
requirements in the existing categories. What you are saying is that 
there is an acceptance policy that says "dont accept unless I can 
encrypt towards this used", and a content policy which says that the 
notifications are to be encrypted.

Now, determining that you can encrypt notifications towards a subscriber 
is a bit hard. I see a few ways:

   * the SUBSCRIBE was received using sips
   * the SUBSCRIBE was authenticated using S/MIME, and included a cert 
for the subscriber
   * a cert for the subscriber exists in the presence server

Similarly, encrypting notifications can occur with sips or with smime.

> other communication channel (e.g. phone or face-to-face 

Thats possible, although its better if you act as your own CA and hand 
these folks certifications. Much more secure.

> that determines the minimum security requirements for subscriptions 

As I propose above, I think there are security aspects to the existing 
components, and I would rather distribute your requirements to those.

> security functions to be used with subscriptions and notifications. 

I would state as:

* it MUST be possible for a user to specify that a subscription should 
not be accepted unless the subscriber is authenticated with a specific 
mechanism (smime, digest, etc.)

* it MUST be possible for a user to specify that a subscription should 
not be accepted unless the notifications to that subscriber can be encrypted

* it must be possible for a user to specify that a notification should 
be encrypted

Now, whether you want to use this protocol to upload digest shared 
secrets, for example, I am not sure...

-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