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

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

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]]On 
 > Behalf Of
 > 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 
 > 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
 > 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 02 Dec 2003 15:17:00 -0500

inline.

[email-masked] wrote:

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

Furthermore, I just dont think that solving this problem is in the 
scope of our activity.

Assuming that someone, somewhere, did manage to do build a system that 
  did this, it can easily be integrated with xcap. When you hand out 
passwords, you also hand out usernames (i.e., identities that can be 
authenticated by the system). Then, the normal applies-to field would 
be able to specify policies associated with that authenticated 
identity. So, I may be [email-masked], but I may have also 
received a username [email-masked] and password, which were 
given to me and associated with a specific context (i.e., the 
conference call).

This point aside, I think that we do have consensus to remove the list 
of authentication types (basic, digest, tls, etc.) from xcap.

What is not clear from the thread is whether we need a way to say 
"this applies to users who have not authenticated at all". I don't 
think this is the same as anonymous, though its similar. I'm also not 
sure that this would get used in practice; I'm not sure a user can 
understand what it means. As such, I would prefer to forgo this 
feature as well.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 02 Dec 2003 15:17:00 -0500

inline.

-Jonathan R.