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