Subject: Re: [Emu] comments on draft-ietf-emu-eaptunnel-req-02.txt, part 1

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Jun 2009 17:24:00 +0200

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.