Hi David, On Wed, May 03, 2006 at 08:31:36PM -0400, [EMAIL PROTECTED] wrote: > 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.
OK. > > 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. I understand. I agree on replacing all IKEv1 references with IKEv2 references. > > 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. OK. I agree on having additional information on this. Thank you, Yoshihiro Ohba > > 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
