[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Radius-Geopriv: User Identity Confidentiality
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
>
--
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/>