Hi Stefan, Thanks for doing this review. Comments inline below
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Stefan Winter > Sent: Friday, August 08, 2008 7:10 AM > To: emu@ietf.org > Subject: [Emu] Review of emu-eaptunnel-req-00, chunk 1 > > Abstract > ------------ > > "The tunnel will provide support for password authentication, > EAP authentication and the transport of additional data for > other purposes." > This wording excludes means of authentication that are > neither based on passwords nor EAP (while it should be > invariant to the tunnel what's transported inside). Suggest > to re-word to ... provide support for authentication (both > EAP and non-EAP) and the transport of additional data for > other purposes. > [Joe] I think this will need more discussion. While the tunnel can carry lots of different things I think we need to focus on a constrained set. We started with just passwords and then added EAP methods. This could be future work, I don't think we need (or want) to tackle it now. > 1. Introduction > ---------------- > > The second sentence misses a reference behind PEAP. > [Joe] Anybody have a reference for PEAP? > 2. Conventions > --------------------- > > Looking at RFC2119, it seems that that RFC is well applicable > also to non-standards-track RFCs. ("Key words for use in RFCs > to Indicate Requirement Levels", "This document defines these > words as they should be interpreted in IETF documents.") Is > it really necessary to create an own wording definition here? > [Joe] The issue isn't between standard and non standard, but rather between protocol vs. requirements. We are following the same conventions as NEA so these are not totally new. > 3.1 Password Auth > -------------------------- > > "support for minimal management tasks including password > change". I fail to see why a management mechanism to *change* > the password is needed > *during* the authentication... ? > [Joe] This was indicated as useful as in some systems the user may not be able to fully authenticate before they change their password. > 3.4 Id Protection > ---------------------- > > The intent of this section is unclear to me. > > "... If an inner method also provides identity protection, > this protection > MUST extend all the way to the server that terminates that inner > method. " > > ... "this" refers to which method, the inner or the outer? If > > outer) it appears impossible to me that the outer tunnel can > possibly ensure that the id protection extends beyond its > termination point, up to the endpoint of the inner > inner) this would put a requirement on the inner method, > which appears odd in document that should describe > requirements for the outer method. > [Joe] I agree this is a bit strange, perhaps we can remove this sentence. > 3.8 Resource constrained Environments > ------------------------------------- > > The document has the implicit requirement to use TLS for the > tunnel method, which is computationally intensive in itself. > A device which is able to establish a TLS tunnel apparently > has a decent amount of computational resources. Plus, the > definition of resource contrained device is quite fuzzy: > "little" processing power, "small" memory, "small" amount of > storage. This section doesn't add a lot of value to the > document IMHO. I suggest to delete it altogether. > [Joe] This needs more discussion. > > 4.1.1 RFC compliance > ------------------------------- > > This section can be largely condensed. It references RFC4017 > as a mandatory reference and requires unconditional > compliance to that RFC, but repeats parts of the content of > that RFC in a different wording, which appears redundant. > [SW] annotated full text of section below: > > The tunnel method MUST include a Security Claims section with all > security claims specified in Section 7.2 in RFC 3748 [RFC3748]. In > addition, it MUST meet the requirement in Sections 2.1 and > 7.4 of RFC > 3748 that tunnel methods MUST support protection against > man-in-the- > middle attacks. Furthermore, all tunnel methods MUST support > identity protection as specified in Section 7.3 in RFC 3748. > > [SW] Sentence 2 (MITM protection) is already contained in > item [6] in RFC4017. Suggest to to delete sentence. > [SW] Sentence 3 (id prot) is already contained in item [9] in > RFC4017. Suggest to to delete sentence. > > > The tunnel method MUST be unconditionally compliant with RFC 4017 > [RFC4017] (using the definition of "unconditionally compliant" > contained in section 1.1 of RFC 4017). This means that the method > MUST satisfy all the MUST, MUST NOT, SHOULD, and SHOULD NOT > requirements in RFC 4017. > > The tunnel method MUST meet all the EAP method > requirements contained > in the EAP Key Management Framework draft [I-D.ietf-eap-keying] or > its successor. The tunnel method MUST include MSK and EMSK > generation. This will enable the tunnel method to > properly fit into > the EAP key management framework, maintaining all of the security > properties and guarantees of that framework. > > [SW] MSK and EMSK generation are already contained in item > [2] in RFC4017. Suggest to delete the last two sentences. > > The tunnel method MUST NOT be tied to any single cryptographic > algorithm. Instead, it MUST support run-time negotiation to select > among an extensible set of cryptographic algorithms. This > "cryptographic algorithm agility" provides several > advantages. Most > important, when a weakness in an algorithm is discovered > or increased > processing power overtakes an algorithm, users can easily > transition > to a new algorithm. Also, users can choose the algorithm that best > meets their needs. > > [SW] Algorithm independence is already contained in item [7] > of RFC4017. The wording isn't so clear to me, but at least > the Security Considerations section in RFC4017 claims that it > is the case. Suggest to delete the para. > > The tunnel method MUST meet requirements pertinent to EAP method > contained in Section 3 of RFC 4962 [RFC4962]. This includes: > cryptographic algorithm independence; strong, fresh session keys; > replay detection; keying material confidentiality and integrity; > confirm cipher suite selection; and uniquely named keys. In > addition, the tunnel method MUST support EAP channel bindings to > enable a system based on EAP to meet the additional requirements in > Section 3 of RFC 4962. > > [SW] The reference to 4962 seems strange: that RFC does not > specify requirements on EAP types, but on AAA Key Management > Protocols. There is only few mentioning of EAP types in the > documents. All the requirements listed in this para are > mentioned in RFC4962 as desired properties of /AAA Key > Management Protocols/. Worse, RFC4962 states "However, an EAP > method MAY depend on a specific cryptographic algorithm.", > which is confusing to the requirements in this draft which > state otherwise. Suggest to delete para. > [Joe] Some of the text may be redundant, but I'm not sure they are a problem. We spent some time on this text so I would like to hear the opinion of the authors. > > 4.2.1.4 Peer Id Privacy > -------------------------------- > > This is already a MUST support due to the requirement of > unconditional compliance with RFC4017. So I wonder if this > needs to be re-iterated here. > [Joe] I don't really see a problem with stating it, especially since it can be clarified somewhat. > 4.2.1.5 Session Resumption > --------------------------------------- > > Session Resumption is a "MUST support". It is certainly a > desirable property to lower needed re-auth round-trips, but I > don't see why it is crucial. I wonder if a SHOULD would do. > [Joe] Well, if the method doesn't provide this I'm not sure people will really want to use it. I agree its not critical to getting the job done, but I think its necessary to have a decent solution. > Greetings, > > Stefan Winter > > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - Réseau Téléinformatique de l'Education > Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg > > Tel: +352 424409 1 > Fax: +352 422473 > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
