Radius-Geopriv: User Identity Confidentiality

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

hi all, 
hi jari,

jari provided input to the section about user identity confidentiality and
listed a few references that should replace some paragraphs. 

here is jari's comment:

>    One way to ensure that the visited network and intermediate networks
>    are incapable to learn the user identity is to use EAP methods that
>    hide the user's identity either actively or passively.  Some EAP
>    methods (such as [16]) protect the user's identity against passive
>    adversaries by utilizing temporal identities.  In some cases the
>    visited network is still able to retrieve the plaintext identity of
>    the user and user identity confidentiality is only provided against
>    eavesdroppers at the wireless link.  Depending on the movement
>    patters of the user, the network topology and available roaming
>    agreements it is possible that a AAA broker is able to see both the
>    plaintext user identity and subsequent temporal identities.
>    Associating location information and the user identity is possible in
>    these cases.
> 
>    It is assumed that the true username is not carried within the
>    initial EAP-Identity Request/Response message exchange.  Support for
>    username privacy is supported with [17].
> 
>    For stronger security and privacy protection active user identity
>    confidentiality is highly suggested.  EAP methods such as [18] or
>    [19] provide such a protection.
> 
>    Unfortunately, most users are not educated about the importance of
>    user identity confidentiality and many EAP methods do not provide
>    active user identity confidentiality.  User identity confidentiality
>    is often treated as an exotic feature which mainly aims to prevent
>    eavesdroppers on the wireless link to learn the user identity of the
>    attached users.  Awareness for this threat type does often not exist.
>    In many cases it is even not possible for users to freely select
>    their favorite authentication and key exchange protocol (based on
>    their security requirements).  Instead the choice is often
>    predetermined by a given architecture.

[jari]
There seems to be several problems with the above text. First of all, I do
not necessarily agree that [18] and [19] provide better identity privacy
than [16] and [17]. The privacy results depend highly on configuration in
all of the cases. For instance, [16] says that clients can refuse to give a
cleartext identity. Depending on configuration and back-end side
implementation, this is possible in some networks and not possible in some
others. Similarly, [18] depends highly on the configuration of the trusted
public key/CA.
If it is the single server's key then you are very safe. If its the Verisign
general purpose CA, anyone with a web side cert can get you to reveal your
identity.

The second issue is that this is IMHO the wrong document to talk about
identity privacy. You should talk about location privacy, but identity
privacy is a larger subject than something that EAP methods can do. For
instance, we have identity privacy problems at the MAC, EAP, PPP, IP, ND,
and application layers.

[hannes] jari suggests to remove the above text and associated references.

[hannes] the first issue: it is true that user identity confidentiality also
depends on the configuration of certain protocols (particularly if protocols
provide flexible mechanisms). in any case, authentication and key exchange
protocols which offer public key based authentication are able to provide
better user identity confidentiality than protocols which only use symmetric
keys. the latter protocols are only able to use temporal identities. 

[hannes] regarding the second issue: 'we should talk about location privacy
rather than user identity confidentiality'

here is my reasoning: 
* we would like to avoid that the visited network obtains the user's
identity and its location information. the visited network will obviously
always obtain the user's location information. hence, we should avoid that
it receives the user's identity. within the radius-geopriv document we can
only address aspects which are within the scope of radius (or diameter) and
certainly not within the scope of other protocols. 
* i know that user identity confidentiality is a difficult issue since you
need to deal with a number of identities at different layers and with
different protocols. i think it is worth stating that providing user id.
conf. within eap does not solve all issues. if you use ikev2 afterwards and
again reveal your true identity then you have again lost. 

i some sense this is not a problem for radius-geopriv, as such, since you
need to deal with this problem also if there is no radius-geopriv extension.


with regard to location privacy (what information is distributed to other
networks or entities by the home network) i tried to say a few words in
section 14. 
 
jari, what should i do? 

ciao
hannes

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>