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

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Nov 2003 01:12:54 -0500

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

---

From: [email-masked]
Date: Mon, 24 Nov 2003 13:54:15 +0200

Can the user at least have a say in accepting or rejecting the subscription based on the availability of any authentication type. Eg: A user can reject subscriptions that are not authenticated in any way and accept subscriptions that are authenticated, regardless of authentication type.

Regards,
Hisham

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 24.November.2003 08:13
> To: Simple WG
> Subject: [Simple] xcap/geopriv alignment issue 4: authentication
> 
> 
> Folks,
>

---

From: [email-masked]
Date: Tue, 25 Nov 2003 10:19:57 +0200

> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: 24.November.2003 23:00
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Simple] xcap/geopriv alignment issue 4: authentication
> 
> 
> [email-masked] wrote:
> 
> > Can the user at least have a say in accepting or rejecting 
> the subscription based on the availability of any 
> authentication type. Eg: A user can reject subscriptions that 
> are not authenticated in any way and accept subscriptions 
> that are authenticated, regardless of authentication type.
> 
> In the absence of _some_ authentication, what is the value of having 
> authorization policies in the first place? They have no 
> meaning if you 
> cannot put some degree of trust in the requestor identity.
> 
> I think the email world has proven to us how useful it is to 
> authorize 
> on un-authenticated headers. How useful is a spam filter that 
> relies on 
> the From header?

Either I'm missing your point, or you missed mine. All I said was that the user should be able to reject subscriptions if they are not authenticated (authentication method is irrelevant).

/Hisham

> >>From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> >>ext Jonathan Rosenberg

---

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 25 Nov 2003 18:07:05 +0100

Hi hisham, 

We had a long discussion on the different authentication mechanisms and our
conclusion was that it is technical very difficult to differentiate the
different levels of authentication. You can easily see our shift over the
past few drafts in the Geopriv working group. 

The differentiation between tls, http digest, etc. as authentication
mechanism is of little value. I guess Jonathan's proposal is to remove these
authentication mechanisms and to replace them with 
- anonymous and 
- everything else is authenticated (i.e., identities are provided within the
rule).

I guess that this also goes inline with your proposal. 

Ciao
Hannes 

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, November 24, 2003 12:54 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [Simple] xcap/geopriv alignment issue 4: authentication
> 
>

---

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 25 Nov 2003 18:07:05 +0100

Hi hisham, 

Ciao
Hannes

---

From: [email-masked]
Date: Tue, 25 Nov 2003 19:34:06 +0200

> From: ext Tschofenig Hannes [mailto:[email-masked]]
> Sent: 25.November.2003 19:07
> To: Khartabil Hisham (NMP-MSW/Helsinki); [email-masked];
> [email-masked]

You seem to describe it that way. I'm happy with that.

/Hisham

---

From: [email-masked]
Date: Tue, 25 Nov 2003 19:34:06 +0200

/Hisham

---

From: [email-masked]
Date: Wed, 26 Nov 2003 17:56:36 +0200

<snip/>
 > btw, a small note. Stating tls as authentication mechanism 
 > is actually wrong
 > since you have to indicate which protocol was used within 
 > the tls handshake,
 > e.g., 
 > - Kerberos
 > - Unilateral pk-based authentication
 > - Mutual pk-based authentication
 > - Shared secret authentication
 > - strong-password based authentication using srp

Worse yet, in SIP, the use of TLS tells the presence server nothing about the actual authenticity of the From field. The From could still be spoofed by the originator of the SUBSCRIBE, even when the previous hop (or in fact all of the hops) successfully authenticated itself in TLS.

BTW, I agree that enumerating authentication mechanisms in authorization policy adds no value. Any unauthenticated identity should be treated as anonymous, as should of course all really anonymous watchers.

Cheers,
Aki

 > ciao
 > hannes
 > > Sent: Dienstag, 25. November 2003 09:20
 > > To: [email-masked]
 > > Either I'm missing your point, or you missed mine. All I said 
 > > was that the user should be able to reject subscriptions if 
 > > they are not authenticated (authentication method is irrelevant).
 > > 
 > > /Hisham
 > > 
 > > > 
 > > > > 
 > > > > Regards,
 > > > > Hisham
 > > > > 
 > > > > 
 > > > >>[email-masked] https://www1.ietf.org/mailman/listinfo/simple
 > > > >>
 > > > > 
 > > > > 
 > > > > [email-masked] https://www1.ietf.org/mailman/listinfo/simple
 > > > 
 > > > 
 > > > 
 > >

---

From: [email-masked]
Date: Wed, 26 Nov 2003 17:56:36 +0200

<snip/>

Cheers,
Aki

---

From: "Vesa Torvinen (JO/LMF)" <[email-masked]>
Date: Thu, 27 Nov 2003 16:19:01 +0100

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

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

Comments?

-Jonathan R.

---

From: "Vesa Torvinen (JO/LMF)" <[email-masked]>
Date: Thu, 27 Nov 2003 16:19:01 +0100

Hi, 

Vesa

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

Folks,

Comments?

-Jonathan R.