Subject: [Geopriv] Radius-Geopriv: User Identity Confidentiality

From: Tschofenig Hannes <[email-masked]>
Date: Mon, 13 Dec 2004 10:06:15 +0100

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

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 13 Dec 2004 18:00:21 +0200

> provide flexible mechanisms). in any case, authentication and key exchange

Yes.

> keys. the latter protocols are only able to use temporal identities. 

Yes, but does that affect the level of privacy offered to the user?
Both approaches can certainly be made to fail, e.g., through bad
configuration or through protocols that don't take into account
all cases.

> it receives the user's identity. within the radius-geopriv document we can

This is very reasonable.

> certainly not within the scope of other protocols. 

This is a good approach, but its kind of hard to draw the line. EAP is
strictly speaking another protocol, although its carried in AAA; and
many L2 protocol issues from a NAS will be reflected in the AAA protocols
in the same manner.

> again reveal your true identity then you have again lost. 

Yes.

> need to deal with this problem also if there is no radius-geopriv extension.

Yes.

> networks or entities by the home network) i tried to say a few words in

I think that part was fine.

> jari, what should i do? 

Lets see if we can work on text:

    For the envisioned usage scenarios the network access authentication
    ...
    their security requirements).  Instead the choice is often
    predetermined by a given architecture.

=>

    For the envisioned usage scenarios, the identify of the user or his
    devices is tightly coupled to the transfer of location information.
    If the identity can be determined by the visited network or AAA
    brokers, then it is possible to correlate location information with
    a particular user. As such, it allows the visited network and
    brokers to learn movement patterns of users.

    The identity of the user can "leak" to the visited network or AAA
    brokers in a number of ways:

    o  The user's device may employ a fixed MAC address, or base its IP
       address on such an address. This enables the correlation of the
       particular device to its different locations. Techniques exist
       to avoid the use of an IP address that is based on MAC address
       [RFC 3041]. Some link layers make it possible to avoid MAC
       addresses or change them dynamically.

    o  Network access authentication procedures such as PPP CHAP [RFC
       1994] or EAP [RFC 3748] may reveal the user's identity as a part
       of the authentication procedure. Techniques exist to avoid
       this problem in EAP, for instance by employing private Network
       Access Identifiers (NAIs) in the EAP Identity Response message
       [draft-ietf-radext-rfc2486bis-03.txt] and by method-specific
       private identity exchange in the EAP method [16, 18, 19].
       Support for identity privacy within CHAP is not available.

    o  AAA protocols may return information from the home network to
       the visited in a manner that makes it possible to either identify
       the user or at least correlate his session with other sessions,
       such as the use of static data in a Class attribute [RFC 2865]
       or in some accounting attribute usage scenarios
       [draft-ietf-radext-chargeable-user-id-00.txt].

    o  Mobility mechanisms may reveal some permanent identifier
       (such as a home address) in cleartext in the packets relating
       to mobility signaling.

    o  Application protocols may reveal other permanent identifiers.

    Note that to prevent the correlation of identities with location
    information it is necessary to prevent leakage of identity
    information from all sources, not just one.

    Unfortunately, most users are not educated about the importance of
    identity confidentiality and there is a lack of support for it in
    many protocols. This problem is made worse by the fact that the
    users may be unable to choose particular protocols, as the choice
    is often dictated by the type of network they wish to access, the
    kind of equipment they have, or the type of authentication method
    they are using.

    A scenario where the user is attached to the home network is, from a
    privacy point of view, simpler than a scenario where a user roams
    into a visited network since the NAS and the home AAA are in the same
    administrative domain.  No direct relationship between the visited
    and the home network operator may be available and some AAA brokers
    need to be consulted.  With subscription-based network access as used
    today the user has a contractual relationship with the home network
    provider which could allow higher privacy considerations to be
    applied (including policy rules stored at the home network itself for
    the purpose of restricting further distribution).

    In many cases it is necessary to secure the transport of location
    information along the RADIUS infrastructure.  Mechanism to achieve
    this functionality are discussed in Section 15.

Does this work for you? Feel free to edit...

--Jari