Glen Zorn wrote: I would suggest that the authors submit an updated version of the document, addressing Glen's concerns. Most seem to be straightforward to resolve.
> Section 3.1, first paragraph, last two sentences say: > > The tunnel method MUST support this use case. > However, it MUST NOT expose the username and password to untrusted > parties and it MUST provide protection against man-in-the-middle and > dictionary attacks. The combination of the tunnel authentication and > password authentication MUST enable mutual authentication. > > By whom (or what) are the "untrusted patties" referred to not trusted? For > example, the AAA proxies in a visited network are certainly trusted _by that > network_ (and by inference, the home network) but they may not be trusted > (at least as much) as similar entities in the home network _by the user_. > Some clarification of the trust model seems to be necessary here, especially > given the specification of absolute requirements in the text. I would say entities trusted to know the username and password can have access to them. This is normally the end user, the server validating the username/password, and no one else. > This might also be a good place to mention that certain data related to > authorization may need to be communicated to the peer; it is forbidden to do > this in an EAP Success message, but there is no such constraint (yet) upon > the TLS tunnel. It may be useful to do this in a TLS tunnel. I would suggest that doing this is permissible, and not forbidden. > Section 3.8, first sentence of first paragraph says: > > The tunnel method MUST provide extensibility so that additional types > of data can be carried inside the tunnel in the future. > > This statement seems awfully broad to me. Do we really mean _any_ > "additional types of data" or is it "additional types of security-related > data" or maybe "additional types of data related to network access"? I would suggest authentication and authorization data can be carried in the tunnel. Other types of data SHOULD NOT be carried in the tunnel. > While it is undoubtedly tempting to simply require compliance with RFC 5247, > given the rather incredible amount of drivel and nonsense present in that > RFC, it might be a better idea to be specific about precisely what > requirements need to be satisfied. This seems slightly more contentious to me. If the authors can submit a document *without* addressing this issue, we can focus discussion to obtain WG consensus on how best to resolve this issue. I would prefer not to re-visit RFC 5247. If there are things which are *wrong* in that document, we could update the tunnel requirements document to say "no need to follow section X.Y of 5247". Otherwise, the presumption should be that 5247 applies. > Same section, last paragraph: same comment as the last, but in spades. Just > one example that leaps out: Section 4.1.1, 4th paragraph of the draft in > question says "The tunnel method MUST NOT be tied to any single > cryptographic algorithm." and the last paragraph says "The tunnel method > MUST meet requirements pertinent to EAP method contained in Section 3 of RFC > 4962 [RFC4962]. This includes: cryptographic algorithm independence..." but > the subsection on algorithm independence in Section 3 of RFC 4962 says > "...an EAP method MAY depend on a specific cryptographic algorithm." While > this specific contradiction might be addressed by adding a sentence stating > that conflicts are resolved in favor of this draft other, more subtle > problems might not. This issue requires more WG discussion. I think that clarification is necessary. Given current state of affairs, having a tunneled method that is not tied to a specific cryptographic algorithm seems beneficial to me. The concern with this is that cryptographic negotiation is hard. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
