Yoshihiro Ohba wrote: > 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. > David is right, we typically publish Framework documents Informational.
- Mark > >> 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
