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: *"internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>"
<internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>>
*Subject: **I-D Action: draft-nir-ipsecme-erx-04.txt*
*Date: *May 21, 2012 8:53:57 AM GMT+03:00
*To: *"i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>"
<i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org>>
*Reply-To: *"internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>" <internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org>>
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
i-d-annou...@ietf.org
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.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
