Subject: Re: [Emu] EMU charter revision

From: "Dorothy Stanley" <[email-masked]>
Date: Tue, 12 Feb 2008 08:13:01 -0800

Hi Joe,

I have 3 comments, listed below.

Thanks,

Dorothy Stanley
---------------------------

1. 3rd list item:

- 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 and
it must provide cryptographic algorithm agility. This mechanism will
support meeting the requirements of an enhanced TLS mechanism, a
password based authentication mechanism, and additional inner
authentication mechanisms.

In the last sentence, "support meeting the requirements of" is somewhat
vague.
What does "support" really mean here? Requirements on the WG in the charter?
requirements of specific methods?

Suggest changing from:

"This mechanism will
support meeting the requirements of an enhanced TLS mechanism, a
password based authentication mechanism, and additional inner
authentication mechanisms."

to

"This mechanism will
provide an enhanced TLS mechanism, a
password based authentication mechanism, and additional inner
authentication mechanisms."

2. List item 5
- 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 tunnel method work item.

Suggest changing the last sentence from

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

to

"This item may be
based on the tunnel method work item."

This change enables the group to use the tunnelled method to satisfy the
requirement, but does not
eliminate the possibility of using a separate protocol, and maintains a
valid charter in either case.

3. First sentence under "Description"

Suggest changing from

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

to

The Extensible Authentication Protocol (EAP) [RFC 3748] is a network
access authentication framework used in the PPP,  IEEE 802.11 and IEEE
802.16
networks, VPNs, PANA, and in some functions in 3G networks."

---------end-of-comments--------------------

On Feb 4, 2008 9:12 PM, Joseph Salowey (jsalowey) <[email-masked]>
wrote:

> Below is a revised charter update based on the discussion on the list.
> I have left the password based method item as a tunnel method because
> this represents the consensus the working group has reached.  I also
> believe the working group will have to focus on the tunnel method
> related items for the near term to make progress.  This does not mean
> that we cannot work on additional methods as working group items in the
> future.
>
> Please review the charter update and post any issues you have with the
> carter.  Please also indicate if you have reviewed the proposed charter
> and have no issues.  It is difficult to judge working group consensus
> unless there are sufficient responses.
>
> 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 and
> it must provide cryptographic algorithm agility. 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 work item.
>
> - 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 tunnel method work item.
>
> Goals and Milestones:
> Done            Form design team to work on strong shared secret
> mechanism
> Done            Submit 2716bis I-D
> Done            Submit first draft of shared secret mechanism I-D
> Done            Form password based mechanism design team
> Done            Submit 2716bis draft to IESG for Proposed Standard
> Done    Submit Strong Shared Secret Mechanism to IESG
> Apr 2008        Submit Tunnel and Password Method requirements first
> draft
> Jul 2008        Send Tunnel and Password Method requirements to IESG
> Oct 2008        Submit Tunnel Method first draft
> Nov 2008    Submit TLS based method channel binding first draft
> Nov 2008        Submit Password Method first draft
> Feb 2009        Send Tunnel Method to IESG
> Apr 2009        Send TLS based method channel binding to IESG
> Apr 2009        Send Password based method to IESG
>
>
>
> _______________________________________________
> Emu mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/emu
>
_______________________________________________
Emu mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/emu

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 12 Feb 2008 15:05:12 -0800

Hi Dorothy,

Thanks for reviewing the charter.  I agree with your comments 1 and 3.
With regard to 2 the working group has already made the decision to use
a tunnel method for this item.  I believe that the proposal Dan recently
submitted is addressing a different set of requirements than this item
intends.  In the case of the current charter item it cannot be assumed
that the server has access to the raw password or even a consistent
transform of the password in order to interact with legacy databases.
Dan will be able to present his ideas in Philadelphia and we can
determine if there is working group interest in pursuing a method of
this type. 

Cheers,

Joe

> -----Original Message-----
> From: Dorothy Stanley [mailto:[email-masked]] 
> Sent: Tuesday, February 12, 2008 8:13 AM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]
> Subject: Re: [Emu] EMU charter revision
> 
> Hi Joe,
> 
> - 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 and it must provide 
> cryptographic algorithm agility. This mechanism will support 
> meeting the requirements of an enhanced TLS mechanism, a 
> In the last sentence, "support meeting the requirements of" 
> is somewhat vague.
> What does "support" really mean here? Requirements on the WG 
> in the charter? requirements of specific methods?
> 
> Suggest changing from:
> 
> "This mechanism will
> support meeting the requirements of an enhanced TLS 
> mechanism, a password based authentication mechanism, and 
> additional inner authentication mechanisms."
> 
> to
> 
> "This mechanism will
> - 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 tunnel method work item.
> 
> This change enables the group to use the tunnelled method to 
> satisfy the requirement, but does not eliminate the 
> possibility of using a separate protocol, and maintains a 
> "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."
> 
> to
> 
> The Extensible Authentication Protocol (EAP) [RFC 3748] is a 
> network access authentication framework used in the PPP,  
> IEEE 802.11 and IEEE 802.16 networks, VPNs, PANA, and in some 
> functions in 3G networks."
> 
> On Feb 4, 2008 9:12 PM, Joseph Salowey (jsalowey) 
> <[email-masked]> wrote:
> 
>