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

From: Tschofenig Hannes <[email-masked]>
Date: Mon, 20 Dec 2004 09:25:06 +0100

hi jari, 

thanks for your feedback. please see my comments below: 

> Tschofenig Hannes wrote:
> 
> > [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
> 
> Yes.
> 
> > 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.
> 
> Yes, but does that affect the level of privacy offered to the user?
i think so. with symmetric key cryptography there are built-in limitations.
no matter how could your configuration is you will never be able to fully
protect yourself against active adversaries. 

> Both approaches can certainly be made to fail, e.g., through 
> bad configuration or through protocols that don't take into 
> account all cases.

> 
> > [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
> 
> This is very reasonable.
> 
> > only address aspects which are within the scope of radius (or 
> > diameter) and 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.

you are also right. 

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

your text proposal looks great. thanks!

ciao
hannes

> --Jari

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