Ohba-san, Thank you for your response. I have a few comments:
1) The Informational vs. Standards-track RFC issue is for the ADs to decide. 2) My comment on IKE is not the same as Bernard Aboba's. My request is that the references to IKEv1 [RFC 2409] be replaced with references to IKEv2 [RFC 4306], or at least that IKEv2 be referenced anywhere IKEv1 is. If this isn't done now, the Security ADs are likely to ask for it during IESG evaluation. With regard to Bernard's comment, I understand that PANA needs to run EAP in a situation where it may not be possible to use IPsec, and hence I agree with your response to Bernard - namely that EAP encapsulated in IKEv2 is not sufficient to meet PANA's requirements. 3) For two level authentication, I understand your comment: > The use of ID_KEY_ID as IKE identifier is being specified in a > separate standard track document (draft-ietf-pana-ipsec), with > specifying the rule on how to generate the ID_KEY_ID from PANA session > attributes. This way PANA/EAP authentication is bound to IKE > identifier to prevent the man-in-the-middle attack you mentioned > above. That additional information would be good to add to the draft along with a statement that (draft-ietf-pana-ipsec) requires the EP to check that the Key ID is being used with the correct PaC by virtue of the EP learning the IP address that corresponds to the PANA session from the PAA and enforcing use of that IP address with the corresponding key via an appropriate IPsec SPD entry. Section 7.3 may be a more appropriate place for these text additions than Section 4. 4. It looks like I may have misread item 3 in Section 5 - on checking it now, the existing text is fine. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Yoshihiro Ohba [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 03, 2006 4:35 PM > To: Black, David > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [email protected]; > [email protected]; [email protected] > Subject: Re: GenART review of draft-ietf-pana-framework-06.txt > > Hello David Black, > > Thank you for reviewing the pana-framework draft and sorry for delayed > response. Please see my comments in line. > > On Fri, Mar 31, 2006 at 07:29:42PM -0500, [EMAIL PROTECTED] wrote: > > Background for those who may be unaware of GenART: > > > > GenART is the Area Review Team for the General Area of the IETF. > > We advise the General Area Director (i.e. the IETF/IESG chair) by > > providing more in depth reviews than he could do himself of documents > > that come up for final decision in IESG telechat. I was selected > > as the GenART member to review this document. Below is my review, > > which was written specifically with an eye to the GenART process, but > > since I believe that it will be useful to have these comments more > > widely distributed, others outside the GenART group are included. > > > > This review was done as part of IETF Last Call. > > > > Review criteria: "Is this document a reasonable contribution to the > > area of Internet engineering which it covers? If not, what changes > > would make it so?" > > > > This draft is on the right track but has open issues, described > > in the review. > > > > The draft is generally well-written, although I was unable to follow > > all of the details of the Wireless LAN examples, as familiarity with > > the 802.11 protocol suite is assumed. I found a number of issues, > > mostly in the area of security: > > > > This is an informational document using RFC 2119 terminology. It > > needs to say something about why this is the case (e.g., who should > > pay attention to these requirements). There are enough statements > > about things that MUST be done in certain ways that I wonder > > whether this ought to be a standards track document. > > The PANA framework document specifies components that are part of a > complete secure network access solution, but are outside of the PANA > protocol specification. People who consider deployment of PANA and > implements the PANA protocol need to pay attention to the requirements > described in in the PANA framework document. > > Regarding whether this document should be a standard track document or > an informational document, I personally think that this should be a > standard track document for the same reason you mentioned above, but > I'd like to hear opinion from WG chairs and ADs. > > > > > Replace all citations of IKE [RFC 2409] with IKEv2 [RFC 4306], > > as IKEv2 is explicitly cited in some places, is the preferred > > protocol, and IKEv2's ability to tunnel EAP as an authentication > > method may be useful. > > There is a similar comment from Bernard Aboba: > > http://www1.ietf.org/mail-archive/web/pana/current/msg02234.html > > Let me quote the comment and the response to it: > > " > >"If the client for > >PANA configures an IPsec tunnel for enabling per-packet security, > >configuring IP addresses inside the tunnel becomes relevant, for > >which there are additional choices such as IKE [RFC2409]." > > > >Since IKEv2 already handles tunnel setup as well as EAP authentication, > >I was somewhat confused by this. Why would PANA be needed in such a > >scenario? > > IKEv2 does not satisfy the requirements that were set in RFC 4058, most > importantly 4.5.1. For that, and for the various other features of PANA, I > don't think IKEv2+IPsec can substitute PANA+IKEv1/IKEv2+IPsec. That's not to > say there wouldn't be any deployments using the former suite. > " > > > > > Section 3 could use a discussion about the relationship of the access > > network to the network that PANA controls access to. Figure 1 ought > > to show the latter (accessed) network as connected to the EP, and a > > two-cloud ASCII diagram would be very useful. Among other things, > > this would make it clear that the access network is in general a > > shared access network (as opposed to consisting entirely of > > per-client private links, as is the case for DSL), helping set up > > the first paragraph in Section 6. > > OK, we will add two clouds in Figure 1, one for accessed network and > the other for access network, both connected to EP. > > > > > Section 4 talks about authentication at two levels - the lower level > > (link native or IPsec) and EAP over PANA. It needs to describe the > > recommended or required relationships between the identities used > > for these authentications. If there is no relationship, there is > > a potential vulnerability (particularly in the IPsec scenario) to > > a man-in-the-middle attack where the secure channel ends are not > > at the PaC and EP. It appears that in the IPsec case, the preferred > > identity is ID_KEY_ID (i.e., here's a key, trust anyone who presents > > it), which is not the most robust approach. > > The use of ID_KEY_ID as IKE identifier is being specified in a > separate standard track document (draft-ietf-pana-ipsec), with > specifying the rule on how to generate the ID_KEY_ID from PANA session > attributes. This way PANA/EAP authentication is bound to IKE > identifier to prevent the man-in-the-middle attack you mentioned > above. > > > > > Section 5 item 3 (address configuration method) assumes stateless > > address autoconfiguration for IPv6. That's not a correct > > assumption for all IPv6 nodes (see RFC 2461 and its discussion of > > DHCPv6), so either: > > - State an affirmative requirement for stateless address auto- > > configuration (e.g., a PaC supporting IPv6 MUST use stateless > > address autoconfiguration). OR > > - Rewrite this item to include a discussion of DHCPv6. > > In Section 5 item 3 we assume stateless address autoconfiguration for > configuring a link-local address. For non-link-local address, we > don't always assume stateless address autoconfiguration for IPv6. In > fact, the possible use of DHCP is mentioned in the text: > > " > 3. In IPv6, clients automatically configure a link-local address > [RFC2462] when they initialize an interface. Additionally, they > may also configure global address(es) when DHCP or router > advertisements with global prefixes are made available to the > them. > " > > Perhaps we should say DHCPv6 instead of DHCP in the above text. > > > > > The network layer protection paragraph (3rd paragraph) in section 6 > > is a bit unclear. It should be edited to make the following two > > points clear: > > (1) The shared secret obtained from an EAP method is insufficient > > to use as a manual key for an IPsec SA in general, as multiple > > keys are often required, and manual keys cannot be automatically > > rekeyed in general. The recommended way of dealing with this > > is to use the shared secret as a shared secret for IKEv2 > > authentication to generate the required keys and support > > rekeying. > > (2) IPsec requires significant configuration (e.g., crypto algorithms, > > traffic selectors). IKEv2 takes care of this also. > > Point (2) is reasonably well made in the text, but earlier than it > > should be. Point (1) is not as obvious. > > > Yes, these are clearer. We will revise the paragraph based on your > suggestion. > > > > > The last paragraph of section 6 discusses ciphers and ciphering. > > In general, requirements for confidentiality are accompanied > > by requirements for (cryptographic) integrity. The paragraph > > should be rewritten in light of this to make it clear that > > cryptographic integrity will be required in general. Weaknesses > > in link layer security (e.g., WEP) can be a motivation to use > > IPsec in addition to whatever the link layer provides. > > I agree. We will revise the paragraph accordingly. > > > > > Section 7.3 is recommending ID_KEY_ID as the IKE identity. > > This is not the best choice if there are other identities available > > (e.g., if the key is bound to a specific IP address, that IP > > address is a better identity). Even repeating the PANA EAP method > > through IKEv2 may be preferable to ID_KEY_ID. > > Please see my earlier comment on ID_KEY_ID. We are taking a strict > approach to mandate ID_KEY_ID. > > > > > End of Section 9: What are "these EAP encapsulating methods"? > > It should read "these EAP methods". > > Best regards, > Yoshihiro Ohba > > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
