Subject: [IPsec] AD review: draft-nir-ipsecme-erx-04.txt

From: Sean Turner <[email-masked]>
Date: Mon, 02 Jul 2012 19:17:56 -0400

Yoav asked me to do an AD review of draft-nir-ipsecme-erx.  We agreed 
that it'd be all right for me to send my comments here.   They are as 
follows:

0) Overall: A couple of folks that I mentioned this to asked: is anybody 
really doing ERP?  So I'm just curious if they are.  This obviously 
non-blocking.

1) General: In case people missed it, the first EAP message for ERX is 
moved to the initial IKE_AUTH request.  I haven't seen any objections to 
this but I'd like to make sure implementers are okay with this!?

Maybe it's splitting hairs but could you do the following to maintain 
architectural integrity/purity (i.e., not mix them):

    first request       --> EAP(EAP_Initiate/Re-auth),

be this:

    first request       --> N[EAP(EAP_Initiate/Re-auth)],

I guess you could do the same thing for the first response.

2) expand AAA on first use

3) s3 contains the following:

  This Notify replaces the EAP-Initiate/Re-auth-Start message of ERX,
  and therefore contains the domain name, as specified in section
  5.3.1.1 of [RFC5296bis].

Is "replaces" the right word here?  I think what you're saying is that 
the Notify serves the same purpose as the ERX EAP-Initiate/Re-auth-Start 
message?

I went to 5.3.1.1 and I think what you're really pointing to is the 
Domain-Name in 5.3.1, which is an NAI from [RFC4282]?  Maybe switch the 
pointer to 5.3.1.

4) s3: In the intro to the protocol exchanges it says most of the 
optional bits are omitted, but that seems to only be true in the 
IKE_SA_INIT exchanges.  Could the IKE_AUTH exchanged be trimmed down to 
(and depending on comment 0 the first line gets changed too):

     first request       --> EAP(EAP_Initiate/Re-auth),
                             IDi,
                             SA, TSi, TSr,

     first response      <-- IDr, AUTH,
                             EAP(EAP-Finish/Re-auth),

     last request        --> AUTH

     last response       <-- AUTH,
                             SA, TSi, TSr,

Just curious if those optional fields aren't so optional anymore.

5) s3: Do you think the following would help the not so plugged in 
reader to add the following to the figure of the exchanges:

   IKE_SA_INIT
    +-
    |    init request         --> SA, KE, Ni,
    |
    |
    |
    |    init response       <-- SA, KE, Nr,
    +-                           N[ERX_SUPPORTED]

   IKE_AUTH Exchange with EAP
    +-
    |    first request       --> EAP(EAP_Initiate/Re-auth),
    |                            IDi,
    |                            SA, TSi, TSr,
    |
    |    first response      <-- IDr, AUTH,
    |                            EAP(EAP-Finish/Re-auth),
    |
    |    last request        --> AUTH
    |
    |    last response       <-- AUTH,
    |                            SA, TSi, TSr,
    +-

6) s3/6: Don't you have to register the Identification Payload type in 
IKEv2 Identification Payload ID Types?

7) s3.1: I think you need to be clear that the codes 5 and 6 came from 
RFC 5296:

  r/(5 and 6)/(5 and 6) [RFC5296]

and maybe:

  r/or in this document/or in [RFC5296]

8) s3.2: r/EMSKName/EMSKName [RFC5295]

and add it as a normative reference

9) s3.2: r/using the CLASS attribute in RADIUS and Diameter/using the 
CLASS attribute [RFC2865] in RADIUS [RFC2865] and Diameter [RFC3588]

and add RFC2865 and RFC 3588 as an informative references

10) s3.3: r/LDAP/Lightweight Directory Access Protocol (LDAP) [RFC4511]

and add RFC4511 as an informative reference

11) s4: I think you need an normative reference to 3629 for UTF-8 and 
you'll also need to say something more about the encoding.

12) s5: I think you did a good job explaining protecting the clients 
identity.  Can you add some more text about exposing the servers 
identity first and why you don't think it's a problem?

Cheers,

spt

On 5/21/12 3:16 AM, Yoav Nir wrote:
> Hi Sean
>
> Since the IPsecME working group did not accept this document (or at
> least did not accept it enough), we would like to have it published as
> an individual submission.
>
> Will you take it to the IESG for us?
>
> Thanks
>
> Qin & Yoav
>
> Begin forwarded message:
>
>> *From: *"[email-masked] <mailto:[email-masked]>"
>> <[email-masked] <mailto:[email-masked]>>
>> *Subject: **I-D Action: draft-nir-ipsecme-erx-04.txt*
>> *Date: *May 21, 2012 8:53:57 AM GMT+03:00
>> *To: *"[email-masked] <mailto:[email-masked]>"
>> <[email-masked] <mailto:[email-masked]>>
>> *Reply-To: *"[email-masked]
>> <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>>
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>> Title : An IKEv2 Extension for Supporting ERP
>> Author(s) : Yoav Nir
>> Qin Wu
>> Filename : draft-nir-ipsecme-erx-04.txt
>> Pages : 8
>> Date : 2012-05-20
>>
>> This document describes an extension to the IKEv2 protocol that
>> allows an IKE Security Association (SA) to be created and
>> authenticated using the EAP Re-authentication Protocol extension as
>> described in RFC 5296bis.
>>
>> NOTE TO RFC EDITOR: Replace 5296bis in the previous paragraph with
>> the RFC number assigned to draft-ietf-hokey-rfc5296bis (now in the
>> RFC Editor queue)
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-nir-ipsecme-erx-04.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-nir-ipsecme-erx-04.txt
>>
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-nir-ipsecme-erx/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Scanned by Check Point Total Security Gateway.
>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Jul 2012 16:35:03 +0300

Hi Sean

Thanks for the review. My answers are inline.

Yoav

> really doing ERP?  So I'm just curious if they are.  This obviously 

My guess is that it is not widely deployed, because 802.1x is for now not widely deployed. EAP is used in some other contexts, like L2TP VPN clients and cable modem/ADSL dialers, but those don't tend to need support for roaming.

> I guess you could do the same thing for the first response.

The responder has indicated support for ERX in the Initial exchange response, so it is expecting to get an EAP message in the first IKE_AUTH request. I guess architectural integrity is a matter of taste, but to me it seems that EAP messages should go in EAP payloads rather than Notify payloads.

> 2) expand AAA on first use

Last paragraph of section 2. OK, will do.

> Domain-Name in 5.3.1, which is an NAI from [RFC4282]?  Maybe switch the 

Right about the "replace". Section 5.3.1.1 talks about the authenticator operation (sending the EAP-Initiate/Re-auth-Start message and including the domain name TLV), so it seemed appropriate. On the other hand 5.3.1 contains the format of the EAP message, which is different from that of the IKEv2 Notify payload. How about:

   This Notify serves the same purpose as the EAP-Initiate/Re-auth-Start
   message of ERX, as specified in section 5.3.1 or [RFC5296bis]. The 
   domain name included in the payload is the same as that included in
   the Domain-Name TLV as specified in section 5.3.1.1 or the same 
   document.

> Just curious if those optional fields aren't so optional anymore.

You're right. I will, however leave the CERT payload in there, so as not to have this imply that we're not using certs anymore (we're not requiring RFC 5998 compliance)

>    |    last response       <-- AUTH,

I guess so. I'll add headlines next version.

> IKEv2 Identification Payload ID Types?

I don't think so. ID_RFC822_ADDR is already registered, and that is the format of the KeyName-NAI.

>  r/or in this document/or in [RFC5296]

   To clarify, an implementation supporting this specification MUST
   accept and transmit EAP messages with at least the codes for Initiate
   and Finish (5 and 6) (RFC5296bis]), in addition to the four codes enumerated in 
   RFC 5996.  This document is intentionally silent about other EAP codes
   that are not enumerated in RFC 5996 or in that document.

> you'll also need to say something more about the encoding.

OK about the references. Not sure what I could say about this.

> identity first and why you don't think it's a problem?

The KeyName-NAI TLV sent in the IDi payload should be meaningful enough to the Authenticator to be able to look up the true identity of the client, so here, as in regular IKE, the initiator goes first. It's true that for an active MitM, only the server reveals its identity, as opposed to both client and server, but that is a good thing, no?

How about:
   With this variant of the IKEv2 protocol, the initiator never sends its
   identity on the wire, while the server does. An active attacker could
   get the server identity from the exchange, but not the user identity.
   In regular IKE, both the user and gateway identities are exposed to an
   active attacker.

---

From: Sean Turner <[email-masked]>
Date: Fri, 13 Jul 2012 17:15:08 -0400

Yoav,

Response inline.  After posting a new version, just find a non-author 
shepherd to do a write-up and get it me and we'll be off to the races.

spt

> My guess is that it is not widely deployed, because 802.1x is for now not widely deployed. EAP is used in some other contexts, like L2TP VPN clients and cable modem/ADSL dialers, but those don't te…

ack - thanks for the info.

> The responder has indicated support for ERX in the Initial exchange response, so it is expecting to get an EAP message in the first IKE_AUTH request. I guess architectural integrity is a matter of…

Nobody else seems bothered by this so I'll let this go.

> Last paragraph of section 2. OK, will do.

ack

>     the Domain-Name TLV as specified in section 5.3.1.1 or the same

that'll work

> You're right. I will, however leave the CERT payload in there, so as not to have this imply that we're not using certs anymore (we're not requiring RFC 5998 compliance)

ack

> I guess so. I'll add headlines next version.

ack

> I don't think so. ID_RFC822_ADDR is already registered, and that is the format of the KeyName-NAI.

ack

>     that are not enumerated in RFC 5996 or in that document.

I think would work.

> OK about the references. Not sure what I could say about this.

I'm still figuring out the APP area pixie dust, but I guess we can leave 
it to them to tell us what they think we need to say about UTF-8.

>     In regular IKE, both the user and gateway identities are exposed to an

That'll work.

spt

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Jul 2012 00:12:23 +0300

Yoav Nir writes:
> My guess is that it is not widely deployed, because 802.1x is for
> now not widely deployed. EAP is used in some other contexts, like
> L2TP VPN clients and cable modem/ADSL dialers, but those don't tend
> to need support for roaming.

EAP-RP also got just added to the IEEE 802.11ai (fast initial link
setup) specification framework document, so support for it should be
coming to the 802.11 networks in the future. That might allow things
like moving from the company WLAN to the VPN over 3G or similar. On
the other hand you might still want to run VPN over the WLAN too...

> The responder has indicated support for ERX in the Initial exchange
> response, so it is expecting to get an EAP message in the first
> IKE_AUTH request. I guess architectural integrity is a matter of
> taste, but to me it seems that EAP messages should go in EAP
> payloads rather than Notify payloads.

I agree on that. We have EAP payload to transmit EAP payloads and we
should keep that for it...

I do not see any problems having EAP payload in the first IKE_AUTH
request, as it is negotiated beforehand. I.e. server who did send
N(ERX_SUPPORTED) do know how to process it there.

> The KeyName-NAI TLV sent in the IDi payload should be meaningful
> enough to the Authenticator to be able to look up the true identity
> of the client, so here, as in regular IKE, the initiator goes first.
> It's true that for an active MitM, only the server reveals its
> identity, as opposed to both client and server, but that is a good
> thing, no?

I assume you mean that the client ID that is releaved to the active
MitM attacker is that ephemeral username, so it is no use for
attacker? I assume that ephemeral username is still sent in the IKE
EAP packet without any other encryption than normal IKEv2 packet
encryption, thus it is visible to the active MitM attacker. 

>    In regular IKE, both the user and gateway identities are exposed to an

I would replace /its identity on the wire/its real identity on the
wire (only ephemeral identity is transmitted)/.
-- 
[email-masked]