Hi Joe,

  Why are we stating that the PSK method must use a strong shared secret
and the method resistant to dictionary attack must use the tunneled
method? That seems odd. How about something along these lines:

  - A mechanism based on shared secrets that meets RFC 3748 and RFC
  4017 requirements. This mechanism should strive to be simple and compact
  for implementation in resource constrained environments. Preference
  will be given to solutions that can be used with a cryptographically
  weak shared secret and that are resistant to dictionary attack.

If a method based on a shared secret just so happened to not require
a cryptographically strong shared secret and was resistant to dictionary
attack I really hope EMU would accept it and not say, "no, sorry that
is too strong for us, our charter mandates a much weaker solution." Of
course if such a solution was not, for whatever reason, acceptable to the
working group we could fall back on the "must be a strong shared secret"
requirement.

  The tunneled method should be resistant to dictionary attack but if the
non-tunneled one was also resistant to dictionary attack wouldn't that
be goodness?

  regards,

  Dan.

"Joseph Salowey (jsalowey)" <jsalowey at cisco.com> wrote
> Below is a draft of the EMU charter that reflects discussions we had at
> IETF 70.  Please review this and send comments.  I would like to have
> comments in by January 23, 2008.
>
> Thanks,
>
> Joe
>
> Description of Working Group:
> The Extensible Authentication Protocol (EAP) [RFC 3748] is a network
> access authentication framework used in the PPP, 802.11, 802.16, VPN,
> PANA, and in some functions in 3G networks. EAP itself is a simple
> protocol and actual authentication happens in EAP methods.
>
> Over 40 different EAP methods exist. Most of these methods are
> proprietary methods and only a few methods are documented in RFCs. The
> lack of documented, open specifications is a deployment and
> interoperability problem. In addition, none of the EAP methods in the
> standards track implement features such as key derivation that are
> required for many modern applications. This poses a problem for, among
> other things, the selection of a mandatory to implement EAP method in
> new network access technologies. For example, no standards track methods
> meet new requirements such as those posed in RFC 4017, which documents
> IEEE 802.11 requirements for EAP methods.
>
> This group is chartered to work on the following types of mechanisms to
> meet RFC 3748 and RFC 4017 requirements:
>
> - An update to RFC 2716 to bring EAP-TLS into standards track, clarify
> specification, interoperability, and implementation issues gathered over
> the years, and update the document to meet the requirements of RFC 3748,
> RFC 4017, and EAP keying framework documents. Backwards compatibility
> with RFC 2716 is a requirement.
>
> - A mechanism based on strong shared secrets that meets RFC 3748 and RFC
> 4017 requirements. This mechanism should strive to be simple and compact
> for implementation in resource constrained environments.
>
> - A mechanism to support extensible communication within a TLS protected
> tunnel that meets RFC 3748 and RFC 4017 requirements. This mechanism
> must
> support channel bindings in order to meet RFC 4962 requirements.
> This mechanism will support meeting the requirements of an enhanced TLS
> mechanism, a password based authentication mechanism, and
> additional inner authentication mechanisms.
>
> - Enable a TLS-based EAP method to support channel bindings. So as to
> enable RFC 2716bis to focus solely on clarifications to the existing
> protocol, this effort will be handled in a separate document.  This item
> will not generate a new method, rather it will enhance EAP-TLS or the
> TLS based tunnel method.
>
> - A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use
> of existing password databases such as AAA databases.  This
> item will be based on the above tunnel method.




_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu

Reply via email to