Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication

From: "Vesa Torvinen (JO/LMF)" <[email-masked]>
Date: Wed, 26 Nov 2003 09:48:23 +0100

Hi, 

I think this mechanism goes back to a use case where a policy would define that "anyone that knows this password is allowed to subscribe". The user wouldn't exactly be interested in identities - just to be sure that the watcher knows the password. This use case is similar to the policies currently used in phone conferencing systems where the caller just needs to know the conference id, and related password - and not really to authenticate itself. 

I agree with you that forcing the use of S/MIME, TLS or P-Asserted-Identity may not be meaningful. However, having policies that mandates the use of HTTP Digest (or some other password based mechanism) may still be useful. 

Vesa

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Jonathan Rosenberg
Sent: 24. marraskuuta 2003 8:13
To: Simple WG
Subject: [Simple] xcap/geopriv alignment issue 4: authentication

Folks,

Currently, xcap-auth defines an authentication condition. This allows 
you to decide whether to accept or reject a subscription based on the 
type of authentication used in the SUBSCRIBE request.

The geopriv policy specification currently has no such mechanism.

This was discussed during the geopriv meeting in Minneapolis. If you 
think about it for a bit, its not clear how this would actually get 
used. Remember, it is end users that will set these policies. What 
kind of meaningful information can be provided to a user about the 
differences between p-asserted-id and sip-identity and digest 
authentication? What would make a user give permission for one type or 
authentication, and not another? Practically speaking, it doesnt seem 
like its easy to use at all.

As a result, I would propose to remove the authentication condition 
from xcap-auth.

Comments?

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

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

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

---

From: [email-masked]
Date: Mon, 1 Dec 2003 23:23:46 +0200

Hi Alex,

I think this should be the policy of the presence server (even better, unauthenticated users should not be passed to one's domain), not set by each individual user via XCAP. Users don't know anything about "digest" or "basic", so this would be just another cryptic checkbox in the UI at best.

Markus

> ext Alex Audu
> Sent: 01 December, 2003 23:19
> To: Vesa Torvinen (JO/LMF)
> Cc: 'Jonathan Rosenberg'; 'Simple WG'
> Subject: Re: [Simple] xcap/geopriv alignment issue 4: authentication
> 
> 
> I think being able to decide whether to accept or reject a 
> subscription based on
> the type of authentication used in the SUBSCRIBE request is 
> useful. That would
> allow me, for example, to reject clients using a less secure 
> authentication scheme
> or force them to use a more secure one (e.g. Basic Access 
> Authentication vs
> Digest Access Authentication).
> 
> Regards,
> Alex.
> 
> "Vesa Torvinen (JO/LMF)" wrote:
> 
> > Hi,
> >
> > [Tried to send something on this before but haven't seen my 
> mail on the list... this is the second try.]
> >
> > I think this was originally related to a use case where a 
> policy would define that "anyone that knows the password is 
> allowed to subscribe". The presentity wouldn't exactly be 
> interested in authentication in terms of identities (the 
> watcher could be "anonymous") - just to be sure that all 
> authorized watchers know the password. This use case is 
> similar to the policies currently used in phone conferencing 
> systems, i.e. the participant just needs to know the 
> conference id, and related password - and not really to 
> authenticate himself in terms of real identity. One problem 
> is, of course, that the password should be specific to the 
> presentity, e.g. "realm=[email-masked]", not to the 
> "realm=domain.com" as a whole.
> >
> > There has also been some discussion in 3GPP/SA3 on having 
> an option for using a password based authentication in 
> addition to the P-Asserted-Identity header based 
> "authentication". Not all people like this idea, however, it 
> could provide some additional security for 3GPP IP multimedia 
> subsystem. For example, HTTP Digest AKA (that is used to 
> create the P-Asserted-Identity) does not really authenticate 
> the end-user - it authenticates the subscription/device.
> >
> > I agree that forcing the use of S/MIME, TLS or 
> P-Asserted-Identity is not really meaningful. However, having 
> policies that mandate the use of HTTP Digest (or some other 
> password based mechanism) may still be useful.
> >
> > Vesa
> >
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > Jonathan Rosenberg

---

From: [email-masked]
Date: Mon, 1 Dec 2003 23:23:46 +0200

Hi Alex,

Markus

---

From: [email-masked]
Date: Mon, 1 Dec 2003 23:28:50 +0200

Vesa,

I think having a single password for the presentity makes sense as a feature that someone might actually use. It is definitely more useful in conferences, which last only for a short period of time, but probably in some cases for presence too. So I wouldn't be against having this kind of simple mechanism, as long as we find a nice way to incorporate it into the XML schema.

Markus

> ext Vesa Torvinen (JO/LMF)
> Sent: 26 November, 2003 10:48
> To: 'Jonathan Rosenberg'; Simple WG
> Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication
> 
> 
> Hi, 
> 
> I think this mechanism goes back to a use case where a policy 
> would define that "anyone that knows this password is allowed 
> to subscribe". The user wouldn't exactly be interested in 
> identities - just to be sure that the watcher knows the 
> password. This use case is similar to the policies currently 
> used in phone conferencing systems where the caller just 
> needs to know the conference id, and related password - and 
> not really to authenticate itself. 
> 
> I agree with you that forcing the use of S/MIME, TLS or 
> P-Asserted-Identity may not be meaningful. However, having 
> policies that mandates the use of HTTP Digest (or some other

---

From: [email-masked]
Date: Mon, 1 Dec 2003 23:28:50 +0200

Vesa,

Markus

---

From: [email-masked]
Date: Tue, 2 Dec 2003 10:51:10 +0200

Hi Vesa,

First of all, I don't like the single password scheme because of two things. Distributing the key is a pain, and the more people you deliver it to, the weaker it gets. When you stop being friends with one of those people, re-keying is an even bigger pain. Secondly, on the client side, I'd say this is even worse. If I have 500 buddies in my presence application, I most certainly don't want to (manually) manage 500 passwords, perhaps randomly delivered to me via email/IM/SMS. When I switch on my handset, I don't want to spend time typing in digest passwords, etc. So I just don't think this scales enough to make it a useful functionality in a presence system.

But more importantly, I think this introduces authentication mechanisms into XCAP policies the same way enumerating the used authentication mechanism (as in S/MIME, TLS, P-A-ID, etc.) does. This time, you need to specify, that a specific policy pertains to a digest username, not an identity delivered in a From field of a SUBSCRIBE. Users don't understand much about digest usernames, or at least don't know how to differentiate between this and the person's SIP ID, and this coupled with the problematics related to managing passwords, I think this just gets too complicated.

Cheers,
Aki

 > I think this mechanism goes back to a use case where a 
 > policy would define that "anyone that knows this password is 
 > allowed to subscribe". The user wouldn't exactly be 
 > interested in identities - just to be sure that the watcher 
 > knows the password. This use case is similar to the policies 
 > currently used in phone conferencing systems where the 
 > caller just needs to know the conference id, and related 
 > password - and not really to authenticate itself. 
 >