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
On 7/10/12 9:35 AM, Yoav Nir wrote:
Hi Sean
Thanks for the review. My answers are inline.
Yoav
On Jul 3, 2012, at 2:17 AM, Sean Turner wrote:
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.
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.
ack - thanks for the info.
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.
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.
Nobody else seems bothered by this so I'll let this go.
2) expand AAA on first use
Last paragraph of section 2. OK, will do.
ack
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.
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.
that'll work
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.
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
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,
+-
I guess so. I'll add headlines next version.
ack
6) s3/6: Don't you have to register the Identification Payload type in
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.
ack
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]
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.
I think would work.
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.
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.
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?
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.
That'll work.
spt
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
