Internet-Drafts | 19 Nov 2007 09:50
Picon
Favicon

I-D Action:draft-ietf-emu-eap-gpsk-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update Working Group of the IETF.

	Title           : EAP Generalized Pre-Shared Key (EAP-GPSK)
	Author(s)       : C. Clancy, H. Tschofenig
	Filename        : draft-ietf-emu-eap-gpsk-07.txt
	Pages           : 36
	Date            : 2007-11-19

This Internet Draft defines an Extensible Authentication Protocol
method called EAP Generalized Pre-Shared Key (EAP-GPSK).  This method
is a lightweight shared-key authentication protocol supporting mutual
authentication and key derivation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-gpsk-07.txt

To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-emu-eap-gpsk-07.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
(Continue reading)

Joseph Salowey (jsalowey | 19 Nov 2007 21:34
Picon
Favicon

EMU charter update for tunneled method

Below is a proposed update to the EMU charter to add a tunneled method.
The following are the changes to the existing charter:

- add charter item for tunneled EAP method
- modified password based item to make use of the above tunneled method
- modify "enhanced TLS" item to focus on adding channel bindings to a
TLS based mechanism 
- updated milestones 

------------------

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 this 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:
(Continue reading)

Joseph Salowey (jsalowey | 19 Nov 2007 23:03
Picon
Favicon

Draft Agenda for IETF 70

Below is the draft agenda for the EMU session at IETF 70 in Atlanta.
Let me know if you have something you want to present in one of the
sections:

EMU 
TUESDAY, December 4, 2007 
0900-1130 Morning Session I
Cypress
=======================================
1. Administrivia (5 min)
2. Draft updates (10 min)
3. Charter Discussion (40 min)
4. Requirements Discussion (50 min)
5. Method presentations (45 min)
Jouni Malinen | 24 Nov 2007 23:57
Picon

Re: I-D Action:draft-ietf-emu-eap-gpsk-07.txt

On Mon, Nov 19, 2007 at 03:50:02AM -0500, Internet-Drafts <at> ietf.org wrote:

> 	Title           : EAP Generalized Pre-Shared Key (EAP-GPSK)
> 	Filename        : draft-ietf-emu-eap-gpsk-07.txt

Minor editorial comments:

It looks like the general description of MK derivation in '4. Key
Derivation' was not updated to match with the ciphersuite specific
changes in 7.1.3 and 7.2.3.

The following lines:
   o  inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server
   o  zero = 0x00 || 0x00 || ... || 0x00 (KS times)

   o  MK = KDF-KS(zero, PL || PSK || CSuite_Sel || inputString)[0..KS-1]

would need to be changed to:
   o  inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server

   o  MK = KDF-KS(PSK[0..KS-1], PL || PSK || CSuite_Sel || inputString)[0..KS-1]

7.1.3 and 7.2.3:

   MK = GKDF-16 (PSK[0..127], PL || PSK || CSuite_Sel || inputString)
   MK = GKDF-32 (PSK[0..255], PL || PSK || CSuite_Sel || inputString)

The 0..127 and 0..255 are clearly usings bits, but these should be bytes
to be consistent with the 0..KS-1 style used elsewhere, i.e., these
lines should be
(Continue reading)

Joseph Salowey (jsalowey | 27 Nov 2007 02:38
Picon
Favicon

Updated agenda for iETF 70

Below is an updated  agenda for EMU at IETF 70.  Let me know if you have
any corrections or additions.  We also need 2 note takers.  Instead of
wasting time in the meeting looking for note takers it would be helpful
if a few participants volunteered ahead of time.  

Thanks,

Joe

EMU
TUESDAY, December 4, 2007
0900-1130 Morning Session I
Cypress
=======================================
1. Administrivia (5 min)
2. Draft updates (10 min)
3. Charter Discussion (40 min)

- http://www1.ietf.org/mail-archive/web/emu/current/msg00692.html

4. Tunneling methods Requirements Discussion (50 min)

- review current requirements
- tunneling passwords
- tunneling EAP methods
- tunnel establishment
- tunnel extensibility

5. Tunneling Method presentations (45 min)

(Continue reading)

Joseph Salowey (jsalowey | 27 Nov 2007 06:24
Picon
Favicon

Tunneling EAP method requirements

In adding the tunneling method to the charter we need to make sure we
work off a valid set of requirements.  We have a set of requirements
that are based on tunneling passwords:

1. Transport of encrypted password for support of legacy password
databases (REQUIRED)
2. Mutual authentication (specifically authentication of the server)
(REQUIRED)
3. resistance to offline dictionary attacks, man-in-the-middle attacks
(REQUIRED)
4. Compliance with RFC 3748, RFC 4017 and EAP keying (including EMSK and
MSK generation) (REQUIRED)
5. Peer identity confidentiality (REQUIRED)
6. Crypto agility and ciphersuite negotiation (REQUIRED)
7. Session resumption (no password needed) (REQUIRED)
8. Fragmentation and reassembly (REQUIRED)
9. Cryptographic binding  (REQUIRED if additional inner mechanisms are
supported)
10. Password/PIN change (DESIRABLE)
11. Transport Channel binding data (REQUIRED)
12. Protected result indication (REQUIRED) 
13. Support for certificate validation protocols (DESIRABLE)
14. Extension mechanism (in support of 10 - 12) (REQUIRED)

In addition we should consider requirements in the use of the tunneling
and changes to the behavior introduced by tunneling:

1. Tunneling EAP methods for authentication (eg, chaining, result
indication, etc.)
2. Additional data that needs to be tunneled (channel binding, etc.)
(Continue reading)

Joseph Salowey (jsalowey | 27 Nov 2007 23:02
Picon
Favicon

Agenda update

I received some feedback that it would be more productive to move the
method presentations before the requirements discussion so the
requirements discussion can benefit from the lessons learned in the
existing method designs.  The updated agenda looks like:

EMU
TUESDAY, December 4, 2007
0900-1130 Morning Session I
Cypress
=======================================
1. Administrivia (5 min)
2. Draft updates (10 min)
3. Charter Discussion (40 min)

- http://www1.ietf.org/mail-archive/web/emu/current/msg00692.html

4. Tunneling Method presentations (30 min)

- EAP-TTLS (15 min)
http://www.ietf.org/internet-drafts/draft-funk-eap-ttls-v0-02.txt
http://www.ietf.org/internet-drafts/draft-hanna-eap-ttls-agility-00.txt

- EAP-FAST (15 min)
http://www.ietf.org/rfc/rfc4851
http://www.ietf.org/internet-drafts/draft-cam-winget-eap-fast-provisioni
ng-05.txt
http://www.ietf.org/internet-drafts/draft-zhou-emu-fast-gtc-00.txt

5. Tunneling methods Requirements Discussion (60 min)

(Continue reading)

Stephen Hanna | 28 Nov 2007 12:28
Favicon

RE: EMU charter update for tunneled method

Here is my feedback on this proposed charter update.

1) RFC 3748 and RFC 4017 requirements should apply to
   all deliverables. The proposed language omits them
   from the tunneled method deliverable. Please add them
   to that deliverable.

2) Some of the new milestones are not clear. The main
   problem is that there's no verb. For example, what
   does "Tunnel Method requirements" mean? It should
   say "Agree on Tunnel Method requirements" or some such.

3) I think that we should have an Internet Draft on
   "Tunnel Method requirements" that goes through the
   normal approval process to achieve IETF consensus
   and become an RFC. Agreeing on a Tunnel Method is
   a major effort (and quite valuable). We should have
   IETF consensus on the requirements before we start.

   Publishing the requirements as an Internet Draft
   will also make it easier for other standards groups
   to comments, which is probably a good idea in this
   instance.

4) The terms "tunneled" and "tunnel" are used interchangably.
   We should choose one or the other and stick to it. I think
   the term "tunneled" is more common for this usage so I
   suggest that we use that term.

5) In the second paragraph, the "this methods" should be
(Continue reading)


Gmane