RE: [Emu] EMU charter update,

["Joseph Salowey (jsalowey)" <jsalowey at cisco.com>]

Hi Dan, 

> -----Original Message-----
> From: Dan Harkins [mailto:dharkins at lounge.org] 
> Sent: Sunday, January 20, 2008 9:56 PM
> To: emu at ietf.org
> Subject: RE: [Emu] EMU charter update, 
> 
> 
>   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. 

[Joe] The PSK is assumed to be a strong shared secret and is resistant
to dictionary attack.  

> 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.
> 
[Joe] This item of the charter is not open for revision.  The GPSK
document to meet this charter item is in IESG review at this time. 

> 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
> Emu at ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
> 


_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu