[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Ipsec] IKEv2 identifier issue with EAP



I agree that this is likely to become a problem, that any of your
'possible solutions' could be used to fix it (except that I don't
believe the first two 'define the problem away' were serious proposals),
and that the community SHOULD agree on one standard approach to maximize
interoperability.

My favorite would be:
    o  Go against the SHOULD NOT when the given NAI requires this.

...because this also addresses the identity type hint that you say might
be coming. But others have argued heatedly that it is important to
minimize the number of messages in an IKE exchange, and this would
result in an eight message exchange while some of the other proposals
work in six.

I'm really glad it's not my job anymore to herd the cats towards one
approach or the other.

	--Charlie

p.s. If you are going to define a new ID type, it would need to be added
to the IANA registry for IKEv2. The procedure for this is "expert
review". It could probably be defined in some EAP RFC and ratified by
some expert chosen by the security ADs, but I don't know.


-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
Of Jari Arkko
Sent: Monday, August 16, 2004 4:17 AM
To: IPsec WG
Cc: Bernard Aboba
Subject: [Ipsec] IKEv2 identifier issue with EAP


First some background: In traditional EAP usage, the client's identifier
has been determined through the EAP Identity Request/Response exchange.
The identifier is typically a Network Access Identifier (NAI). Basically
an identifier similar to an e-mail address, used to identify the user
and to find the right home network in case of a roaming user.

IKEv2-14 says the following:

    Note that since IKE passes an indication of initiator identity in
    message 3 of the protocol, EAP based prompts for Identity SHOULD NOT
    be used.

it also defines one of the identity type as follows:

    ID_RFC822_ADDR                      3

      A fully-qualified RFC822 email address string, An example of
      a ID_RFC822_ADDR is, "jsmith@example.com".  The string MUST
      not contain any terminators.

In the RADEXT and EAP WGs, we have recently discussed some
problems that this causes. Here are the issues:

1. A revision of the NAI specification, RFC 2486bis, intends
    to extend the existing user@domain format in
    draft-arkko-roamops-rfc2486bis-02.txt, partially based on
    existing practise. This spec is currently in WGLC in the
    RADEXT WG.

    One of the extensions is to allow the client's identity
    to be hidden from the access server / IKEv2 gateway,
    if the used EAP method supports end-to-end encrypted
    tranmission of the identity. Syntactically, this
    happens through specifying an empty username, "@domain"
    but keeping the domain pawrt in order to make the AAA
    routing possible.

    The issue with IKEv2 is strictly speaking, this
    string would be illegal in RFC 822. Hence an IKEv2
    implementation can not be relied upon to accept such
    "privacy" user names.

2. Another extension from this draft is internationalized
    NAIs. The domain parts are IDNs, i.e., converted to ASCII
    via a specific mapping, but the username part is UTF-8.
    Again, this is strictly speaking not conformant to RFC 822,
    so sending an internationalized username via IKEv2 might
    not be possible. For instance, someone might be assigned
    a username for WLAN access, but the usage of this username
    for IKEv2 purposes might not be possible if it contains
    international characters.

    Some of the possible solutions to avoid this problem
    include

    o  Decide that support of privacy & international usernames
       is not necessary in IKEv2.

    o  Remove the privacy and international username (not domain)
       parts from RFC 2486bis.

    o  Change the international username part so that instead of
       UTF-8, it uses a IDN-like ASCII mapping which can represent
       non-ASCII characters but it looks like ASCII to the carrier.
       Either remove the privacy feature or just say it can not
       be used in all carrier protocols.

    o  Define a new IKEv2 ID type to carry the new types NAIs.
       (If so, would this type be defined in the NAIbis, IKEv2
       or some other draft?)

    o  Rely on IKEv2 implementations to not check the contents
       of the identifier for RFC 822 compliance.

    o  Go against the SHOULD NOT when the given NAI requires this.

3. Ongoing work (and some existing practise) provides some
    information through the EAP identity request. More specifically,
    the client can get a hint of what type of identifier it should
    offer. See draft-adrangi-eap-network-discovery-03.txt.

    This functionality does not appear to be present when running
    EAP over IKEv2. (I have not heard of any customer who wanted
    this functionality in this context, but I'd like to avoid
    special cases where possible.)

Comments?

--Jari

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec