Subject: RE: [Emu] EMU charter update,

From: "Dan Harkins" <[email-masked]>
Date: Sun, 20 Jan 2008 21:56:13 -0800 (PST)

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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 22 Jan 2008 12:38:02 -0800

Hi Dan, 

> -----Original Message-----
> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Sunday, January 20, 2008 9:56 PM
> To: [email-masked]
> 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:
> 
[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 
>   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.
> 
> > 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
> >
> > 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:
> >
> > 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 
> > 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.
> 
> 
> 
>

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 22 Jan 2008 14:13:09 -0800 (PST)

Hi Joe,

> [Joe] The PSK is assumed to be a strong shared secret and is resistant

The notion of resistance to dictionary attack is not based on the strength
of the PSK it is based on whether the advantage an adversary can gain to
determine the PSK is based _solely_ on interaction with a protocol
participant. If any advantage can be gained through something like
computation then the protocol is not resistant to dictionary attack.

  The GPSK protocol is NOT resistant to a dictionary attack regardless
of the assumptions placed on the PSK.

> document to meet this charter item is in IESG review at this time.

  That's very curious. A charter that mandates a weak solution and is
not open to revision. What other portions are not open for revision?

  Dan.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 22 Jan 2008 14:41:22 -0800

> Sent: Tuesday, January 22, 2008 2:13 PM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]
> >>   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.
> >
> The notion of resistance to dictionary attack is not based on 
> the strength of the PSK it is based on whether the advantage 
> an adversary can gain to determine the PSK is based _solely_ 
> on interaction with a protocol participant. If any advantage 
> can be gained through something like computation then the 
> protocol is not resistant to dictionary attack.
> 
>   The GPSK protocol is NOT resistant to a dictionary attack 
> regardless of the assumptions placed on the PSK.
> 
[Joe] OK, dictionary attack resistance is not a requirement for GPSK. 

> >> compact
> Preference
>   That's very curious. A charter that mandates a weak 
> solution and is not open to revision. What other portions are 
> not open for revision?
> 
[Joe] The charter is opened up to add support for a tunnel method, a
password based method and to clarify "enhanced TLS".  Other items,
especially items that are near completion, are not open for revision.  

> >> 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.
> >>
> attack but if 
> >> the non-tunneled one was also resistant to dictionary 
> attack wouldn't 
> >> that be goodness?
> >>
> >>   regards,
> >>
> >>   Dan.
> >>

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 22 Jan 2008 17:11:43 -0800 (PST)

Hi Joe,

  OK, so the charter is being opened up to add support for a
password-based mechanism, which should be resistant to a dictionary
attack, and that mechanism must use the tunnel method. Right?

  It looks to me like we're explicitly writing a stand-alone password-based
method (which is resistant to dictionary attack) out of the charter.
That seems odd. Why are we doing that?

  Dan.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 22 Jan 2008 21:17:43 -0800

> Sent: Tuesday, January 22, 2008 5:12 PM
> Cc: Dan Harkins; [email-masked]
> password-based mechanism, which should be resistant to a 
> dictionary attack, and that mechanism must use the tunnel 
> method. Right?
> 
[Joe] Yes, this is the decision the working group made and the reason
why we are opening the charter. 

>   It looks to me like we're explicitly writing a stand-alone 
> password-based method (which is resistant to dictionary 
> attack) out of the charter.
[Joe] We are explicitly adding a charter item for a tunnel method and a
password method based on the tunnel method.  This is the direction the
working group chose.  

> >> The notion of resistance to dictionary attack is not based on the 
> >> strength of the PSK it is based on whether the advantage 
> an adversary 
> >> can gain to determine the PSK is based _solely_ on 
> interaction with a 
> >> protocol participant. If any advantage can be gained through 
> >> something like computation then the protocol is not resistant to 
> >> dictionary attack.
> >>
> solution and is

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 23 Jan 2008 11:34:00 -0800 (PST)

Hi Joe,

  I went back and looked at the mailing list archives and the thing
is I can't really see where the group decided NOT to pursue an EAP
method that is resistant to dictionary attack and is also not based
on a tunnel method.

  The group wants to add a tunnel method and that method should
support passwords as well as other authentication mechanisms. And
I'm all on board for that! But that doesn't mean that password
authentication without a tunnel method is something we should not
work on.

  The working group had consensus for EAP-GPSK over EAP-TLS with TLS-PSK
and for those very same reasons I think an EAP-password method that is
resistant to dictionary attack would be good. Is there some reason why
it wouldn't be good? Is there something I'm missing?

  regards,

  Dan.

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Wed, 23 Jan 2008 14:44:41 -0500

Dan:

Not on the charter doesn't mean it prevent from someone working on such
method. Just the group agreed to develop a tunnel method supports
password authentication as a WG charter item.

> Sent: Wednesday, January 23, 2008 2:34 PM
>   I went back and looked at the mailing list archives and the 
> thing is I can't really see where the group decided NOT to 
> pursue an EAP method that is resistant to dictionary attack 
> and is also not based on a tunnel method.
> 
>   The group wants to add a tunnel method and that method 
> should support passwords as well as other authentication 
> mechanisms. And I'm all on board for that! But that doesn't 
> mean that password authentication without a tunnel method is 
> something we should not work on.
> 
>   The working group had consensus for EAP-GPSK over EAP-TLS 
> with TLS-PSK and for those very same reasons I think an 
> EAP-password method that is resistant to dictionary attack 
> would be good. Is there some reason why it wouldn't be good? 
> Is there something I'm missing?
> 
>   regards,
> 
>   Dan.
> 
> dictionary 
> > [Joe] We are explicitly adding a charter item for a tunnel 
> method and 
> > a password method based on the tunnel method.  This is the 
> direction 
> > the working group chose.
> >
> >>   Dan.
> >>

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 23 Jan 2008 12:35:02 -0800 (PST)

Well of course! Nothing prevents anyone from making an individual
submission. And yes, I understand very clearly that "the group agreed
to develop a tunnel method [that] supports password authentication as
a WG charter item." What I don't seem to see is where the group decided
that development of a non-tunneled EAP method for password authentication
is expressly not an item for the WG charter. That's not in the archives
of the mailing list and it doesn't seem to make much sense to me (for the
reasons I noted below). Care to explain why you, in particular, would not
like to see the WG work on a non-tunneled EAP method that supports
password authentication?

  Dan.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 23 Jan 2008 13:32:44 -0800

Hi Dan,

Comments inline below: 

> Sent: Wednesday, January 23, 2008 11:34 AM
[Joe] The group has decided to work on the set of EAP methods in the
charter.  For the password based method the group has decided to work on
a tunnel method (see list archives October 2007).  While this does not
explicitly exclude another password based method, another password based
method is not within the scope of the charter.  

> something we should not work on.
[Joe] We need to make more progress on the current work items before we
consider taking on new work.  

> Is there something I'm missing?
[Joe] I think there are differing opinions within the group. There is a
strong sentiment that fewer EAP methods is better than more.  Others may
be more liberal with respect to new methods.  Right now it is important
that we make progress on the items that we have consensus on before we
attempt to open up new ones.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 23 Jan 2008 14:01:08 -0800 (PST)

Hi Joe,

  With all due respect to your chairmanship of the group let me
make the following comments.

> method is not within the scope of the charter.

  We are updating the charter. We have consensus to update add
something to it. I do not see how that equates to consensus to not add
something else.

  Strictly speaking a tunnel-based EAP method that supports passwords
is not within the scope of the current charter, right? Which is why the
title of this thread is "EMU charter update". We're updating our charter
to put such a method in our scope. This seems like an opportune time
to put another method in our scope.

> consider taking on new work.

  From the looks of our last meeting we have considerable progress on
that front. In fact, we have 2 competing EAP methods that already
satisfy the requirements! The technical work necessary once we choose
the protocol to advance should be minimal. In fact, due to the claims
of a large deployed base for both protocols I would be inclined to
believe that substantive changes to the selected protocol will be
strongly resisted.

> attempt to open up new ones.

  I understand that is important but, again respectfully, I do not
believe your desire to speed things up necessarily translates into
consensus in the group.

  We certainly do not suffer from a lack of EAP methods but that is
largely due to different flavors of exactly the same thing-- PEAPv0,
PEAPv1, FAST, TTLS all provide server-side authentication with something
that looks awefully like EAP-TLS followed by a generic second phase
which does client-side authentication with a suite of options. What we
do suffer from is some EAP methods providing certain useful functionality.
EAP-GPSK filled one gap (PSK-based authentication that is compact,
lightweight, and does not require certificates) but it  cannot fill
another (robustness and resistance to dictionary attack).

  I respectfully ask you to make a call for consensus on the topic of
adding a password-based authentication method that is resistant to
dictionary attack to our charter.

  regards,

  Dan.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 29 Jan 2008 17:04:52 -0800 (PST)

Hi Joe,

  I don't think I've been very clear. In fact, after speaking to other
people about this topic I'm pretty sure I have not been clear. So let
me try to explain myself again.

  Currently the EMU charter says:

"This group is chartered to work on the following types of mechanisms to
meet RFC 3748 and RFC 4017 requirements:
[snip]
- A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use
of existing password databases such as AAA databases. The
implementation should strive to be usable in resource constrained
environments."

So a method that uses an existing password database _is_ in the charter.
(Note that this was not satisfied by EAP-GPSK nor am I talking about
changing anything about the charter that refers to EAP-GPSK. EAP-GPSK
has an explicit mention in the current charter that is different from
the quoted item above). And the Goals and Milestones say:
"Aug 2007	  	Submit password Based Mechanism to IESG"

  Having a password-based authentication method is very valuable because
it uses a very simple trust model. It can be argued that this trust
model is the predominant one in the Internet today for human to computer
interaction. A method that operates in this simple trust model and uses
no public-key infrastructure would be a valuable contribution that EMU
could make.

  But I should be preaching to the choir because _it's already in the
charter_!!! Certainly the value of this method has already been discussed
in this working group because consensus was reached to have it be in the
charter.

  Now, I also see considerable value in having a tunneled method that
could, just so happen, allow for client-side authentication with a
password. I'd expect it can do a whole suite of options for various
client-side authentication but a password could be one. That's great.
Let's include that in the charter. In fact, that was "Option 2" that
that there was humming for back in October of 2007.

  What is being proposed is modifying the aforementioned charter item
to read:

"- 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."

And it's that last sentence that I'm taking issue with. There is already,
in the proposed charter update, explicit mention of a tunneled method
that will support a password-based authentication mechanism. So adding
that last sentence does nothing except _remove_ something from the charter.

  I do not see any rationale for, or any value in, removing a stand-alone
method that provides password-authentication from the charter. All we
need to do is update the Goals and Milestones. I happen to have a protocol
in mind that I think can satisfy this requirement and I'd like it to find
a home in EMU.

  regards,

  Dan.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 30 Jan 2008 13:40:17 -0800

Hi Dan,

The EMU group was chartered to work on a password based method to work
with existing password databases.  During the last year we have had
discussions in meetings and on the list to reach working group consensus
on the way to meet this task.  The consensus is to use a tunnel method
to meet this task and is the reason why we are adding this to the
charter.  Removing the sentence that indicates use of a tunnel method
from the charter would be counter to the consensus we have reached. 

EMU was chartered with a constrained set of goals, which is why we must
re-charter to add a tunnel method.  Adding a new item requires gaining
consensus within the working group and approval from the IESG.  The
first step in this process would be to have a proposal. 

Joe

> Sent: Tuesday, January 29, 2008 5:05 PM
>   I don't think I've been very clear. In fact, after speaking 
> to other people about this topic I'm pretty sure I have not 
> been clear. So let me try to explain myself again.
> 
> "This group is chartered to work on the following types of 
> mechanisms to meet RFC 3748 and RFC 4017 requirements:
> [snip]
> - A mechanism meeting RFC 3748 and RFC 4017 requirements that 
> makes use of existing password databases such as AAA 
> databases. The implementation should strive to be usable in 
> resource constrained environments."
> 
> (Note that this was not satisfied by EAP-GPSK nor am I 
> talking about changing anything about the charter that refers 
> to EAP-GPSK. EAP-GPSK has an explicit mention in the current 
> charter that is different from the quoted item above). And 
> the Goals and Milestones say:
>   Having a password-based authentication method is very 
> valuable because it uses a very simple trust model. It can be 
> argued that this trust model is the predominant one in the 
> Internet today for human to computer interaction. A method 
> that operates in this simple trust model and uses no 
> public-key infrastructure would be a valuable contribution 
> that EMU could make.
> 
>   But I should be preaching to the choir because _it's 
> already in the charter_!!! Certainly the value of this method 
> has already been discussed in this working group because 
> consensus was reached to have it be in the charter.
> 
>   Now, I also see considerable value in having a tunneled 
> method that could, just so happen, allow for client-side 
> authentication with a password. I'd expect it can do a whole 
> suite of options for various client-side authentication but a 
> password could be one. That's great.
> Let's include that in the charter. In fact, that was "Option 
> 2" that that there was humming for back in October of 2007.
> 
>   What is being proposed is modifying the aforementioned 
> charter item to read:
> 
> "- 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."
> 
> And it's that last sentence that I'm taking issue with. There 
> is already, in the proposed charter update, explicit mention 
> of a tunneled method that will support a password-based 
> authentication mechanism. So adding that last sentence does 
> nothing except _remove_ something from the charter.
> 
>   I do not see any rationale for, or any value in, removing a 
> stand-alone method that provides password-authentication from 
> the charter. All we need to do is update the Goals and 
> Milestones. I happen to have a protocol in mind that I think 
> can satisfy this requirement and I'd like it to find a home in EMU.
> 
>   regards,
> 
>   Dan.
> 
> > charter.  For the password based method the group has 
> decided to work 
> > on a tunnel method (see list archives October 2007).  While 
> this does 
> > not explicitly exclude another password based method, 
> another password 
> > based method is not within the scope of the charter.
> >
> >> support passwords as well as other authentication 
> mechanisms. And I'm 
> >> all on board for that! But that doesn't mean that password 
> > [Joe] We need to make more progress on the current work 
> items before 
> > we consider taking on new work.
> >
> >>   The working group had consensus for EAP-GPSK over EAP-TLS with 
> >> TLS-PSK and for those very same reasons I think an EAP-password 
> >> method that is resistant to dictionary attack would be 
> good. Is there 
> >> some reason why it wouldn't be good?
> > [Joe] I think there are differing opinions within the 
> group. There is 
> > a strong sentiment that fewer EAP methods is better than 
> more.  Others 
> > may be more liberal with respect to new methods.  Right now it is 
> > important that we make progress on the items that we have 
> consensus on 
> > before we attempt to open up new ones.
> >
> >
> >>   regards,
> >>
> >>   Dan.
> >>
> >> >> >> >> > The Extensible Authentication Protocol (EAP) 
> [RFC 3748] is
> >> >> >> >> a network
> >> >> >> >> > proprietary methods and only a few methods are 
> documented
> >> >> >> >> in RFCs. The
> >> >> >> >> > required for many modern applications. This poses a 
> >> >> >> >> > problem
> >> >> >> >> for, among
> >> >> >> >> > other things, the selection of a mandatory to implement 
> >> >> >> >> > EAP
> >> >> >> >> method in
> >> >> >> >> > enable RFC 2716bis to focus solely on clarifications to 
> >> >> >> >> > the
> >> >> >> >> existing

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 31 Jan 2008 00:07:31 -0800 (PST)

Hi Joe,

> from the charter would be counter to the consensus we have reached.

  I don't believe that would be the case. The changes to the charter that
are being proposed say:

 "- 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."

Which is all well and good. It will support a password-based authentication
mechanism. Great! I'm on board! But I'm not talking about that change and I
don't really have a problem with with it.

  The change I'm talking about is adding the following sentence to the
_existing_ item dealing with a stand-alone password method:

   "This item will be based on the above tunnel method."

> first step in this process would be to have a proposal.

  Yes, yes. I understand why the charter is being updated: to add that
stuff above about "A mechanism to support extensible communication within
a TLS protected tunnel...." That's great.

  But I'm not talking about "adding a new item" I'm talking about
_removing_ an existing item. The current charter, not the update that you
asked for consensus on, says:

All I want is to leave that alone. Please, add the new item about the
tunnel method. I'm behind you 100% on that. But hat is a completely
separate issue.

  Yes, we have consensus to ADD a tunneled method. Great. No dispute. But
I don't see how that translates into consensus to REMOVE another item from
the charter. Especially something that obviously has so much value that
the group agreed to put it in its charter in the first place!

  regards,

  Dan.