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

From: "Vesa Torvinen (LMF)" <[email-masked]>
Date: Fri, 25 Oct 2002 11:23:44 +0200

Jonathan, 

In general, I like your version of requirements. Some further comments (with 3GPP'ish hat on): 

1) About the digest passwords: 

There are system architectures in which it is not very likely that Watcher and Presence Server will have direct trust relationship. It is not very likely either that S/MIME is available. My opinion is, that in this kind of context, the procedure for letting the presentity to upload digest passwords would be efficient and cheap solution. 

I am not sure if this issue is a general requirement for this protocol... or even if this is a good idea at all. I would love to hear more opinions about it! 

2) About the encryption: 

Again, there are architectures which may follow some kind of 'transitive trust model', and in which S/MIME or SIPS are not necessarily available. Still, the trust model assumes that it can guarantee confidentiality if requested. In practice, this can be done using IPsec security gateways within the network, and IPsec over the more vulnerable part of the network (i.e. the air interface). In other words, there might be other ways (in addition to sips or certificates) to know that confidentiality can be guaranteed. 

I would talk about 'confidentiality' instead of 'encryption' in the requirements. 

Vesa  

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: 25. lokakuuta 2002 10:43
To: Vesa Torvinen (LMF)
Cc: [email-masked]'; [email-masked]
Subject: Re: Comment on draft-ietf-simple-data-req-00

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

Vesa Torvinen (LMF) wrote:
> 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 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.

> 
> 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). 

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

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

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

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

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
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Michael Hammer <[email-masked]>
Date: Fri, 25 Oct 2002 10:31:25 -0400

Inline.

At 11:23 AM 10/25/2002 +0200, Vesa Torvinen (LMF) wrote:
>There are system architectures in which it is not very likely that Watcher 
>and Presence Server will have direct trust relationship. It is not very 
>likely either that S/MIME is available. My opinion is, that in this kind 
>of context, the procedure for letting the presentity to upload digest 
>passwords would be efficient and cheap solution.

By solution, do you mean to say that this will establish a chain of trust 
between the two?  Is the goal here to assure that notifications are 
integrity or confidentiality protected, or is there any intent to be 
assured that you really know to whom notifications are being sent?

MH

>I am not sure if this issue is a general requirement for this protocol... 
>or even if this is a good idea at all. I would love to hear more opinions 
>about it!
>
>2) About the encryption:
>
>Again, there are architectures which may follow some kind of 'transitive 
>trust model', and in which S/MIME or SIPS are not necessarily available. 
>Still, the trust model assumes that it can guarantee confidentiality if 
>requested. In practice, this can be done using IPsec security gateways 
>within the network, and IPsec over the more vulnerable part of the network 
>(i.e. the air interface). In other words, there might be other ways (in 
>addition to sips or certificates) to know that confidentiality can be 
>guaranteed.
>

---

From: "Vesa Torvinen (LMF)" <[email-masked]>
Date: Mon, 28 Oct 2002 10:46:59 +0100

Michael, 

You seem to ask me how Digest is useful in this context. 

I am thinking a model in which the authentication would take 
place with subscriptions. Integrity protection would probably 
be required to do this securely. If you can re-use the 
authenticated & integrity protected "security tunnel" (e.g. TLS) 
with notifications, you are quite safe in assuming that they 
are sent to the intended recipient. Right? 

If you have to initiate security every time you send 
notification, you may still trust on some SIP headers that 
were authenticated & protected during subscription (e.g. Contact). 
However, Digest would not server the Presence Server to know that 
the recipient is the correct one. Instead, Digest could be used by 
the Watcher to know that the messages really originate from an 
entity that knows the same passwords that was used during 
subscription. 

The confidentiality part is a different story and not really 
related to Digest. The presentity may have an interest to require 
confidentiality protection for all notifications. 

But maybe you were concerned on the semantics of these 'security 
policies' to the end-user? That the end-user would assume better 
security than it actually is? 

Vesa 

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: 25. lokakuuta 2002 17:31
To: Vesa Torvinen (LMF)
Cc: 'Jonathan Rosenberg'; [email-masked]';
[email-masked]
Subject: Re: [Simple] RE: Comment on draft-ietf-simple-data-req-00

Inline.

MH

---

From: Michael Hammer <[email-masked]>
Date: Mon, 28 Oct 2002 11:22:17 -0500

Vesa,

Just doing a "reality check."  From your 3rd paragraph
below, this seems to sum up what is really being
"authenticated":

You "know that the messages really originate from an

subscription."

Most of the schemes I have seen thus far seem to provide little true
authentication of the identity asserted, unless this involves some
infrastructure and security policies that provide some confidence that
such identities correspond with the real world, i.e. could support a
contract in a court of law.  Not that this is always
necessary.  Just wanted to be precise about what is actually
occurring.

Mike Hammer

At 10:46 AM 10/28/2002 +0100, Vesa Torvinen (LMF) wrote:

Michael,

authenticated & integrity protected "security tunnel" (e.g.
TLS)

subscription.

Vesa

-----Original Message-----

From: Michael Hammer
[mailto:[email-masked]]

To: Vesa Torvinen (LMF)

Inline.

>In general, I like your version of requirements. Some further
comments

>(with 3GPP'ish hat on):

MH

>I would talk about 'confidentiality' instead of 'encryption' in the

>requirements.

>Jonathan D. Rosenberg,
Ph.D.
72 Eagle Rock Ave.

>Chief
Scientist
First Floor