[XCON] identity issues

[Tschofenig Hannes <hannes.tschofenig at siemens.com>]

hi hisham, 
hi aki, 
hi petri, 

in a discussion with my co-worker christian schmidt we spoke about one of
your comments on the <unauthenticated> element. in your comments you write:

> Some conferences need to allow unauthenticated users into the 
> conference, or block them. The difference between 
> unauthenticated and anonymous is that in the former, the 
> conference focus does not know who they are. In the latter, 
> the conference focus has authenticated the user, but the user 
> requested anonymity from the conference.

we see different levels of security here: 

1) authenticated identities 

the functionality of the <identity> element aims to focus of authenticated
identities. 

2) unauthenticated identities

you might not care about the authentication of the identities. your policies
list a few identities (a, b and c) and if they connect to a confererence
then you might want allow them to join the conference. however, if another
entity "a'" claims to be "a" then you would 
- either block him (if another entity a is already in the conference) 
- or allow him to join (and block a subsequent entity which claims to be
"a") 
- or allow all entities to join which claim to be "a". 

in some sense there is a relationship with (3). if you tell a few persons
that there will be a conference (and entities a, b and c are allowed to join
the conference) then you need to know that only these entities are allowed
to join. you cannot join if you are entity f.

for many systems the provided security is pretty weak.

with the currenty <unauthenticated> element you cannot provide this
functionality since you would need something like: 

<unauthenticated>
 <id>alice at example.com</id>
<unauthenticated>

3) pin/passcodes 

this is the aspect of non-identity based authorization. 

4) asserted identities

rfc3325 defines the P-Asserted Identity header which carries the network
asserted identity. there is clearly a difference between (1) and (4). 

5) anonymous identity

as you state there are privacy mechanisms defined in sip which prevent
individual entities to be authorized based on their identity. i think that
authorization policies in this case make only sense in the context of (3). 

6) pseudoyms

we haven't discussed the usage of pseudoyms yet. they can either be treated
as (5) or as (1+4) if the identity has a longer lifetime. the relationship
with (3) also makes sense. 

ciao
hannes

_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon