IETF 65 EAP Method Update (EMU)
-----------------------------------
Tuesday March 21, 2006

Compiled from notes taken by Laksminath Dondeti and Nancy Cam-Winget

=========================================================
1. EMU pre shared key design team update (Uri Blumenthal)
=========================================================

Presentation (Uri): EAP method update from the PSK design team
- Goals: Create an EAP method based on a PSK, meets 3748 and 4017 reqs,
  and simple and compact 

- Decisions:
  Not based on TLS-PSK
  symmetric credentials only, no public key based credentials
  No multi-party
  Fast resumption is unnecessary
  Must support channel bindings
  Algorithm agility
  Provisioning out of scope
  Discussion on Key Generation/transport vs. derivation
 
  (David McGrew)): What are the attacks on the transport of keys
  (Uri): chosen-plain text attacks

  (Hannes Tschofenig): I also believe there is room for analysis
   Both end points contributing to key mat is good.

  (Bernard Aboba): Is anyone from NIST part of the design team?
   We want to be proactive about getting input from NIST.

  (Joe Salowey): Jesse, David and Charles have NIST contacts, 
   we have contacted Lily Chen at NIST and made here aware of 
   the EMU efforts.  Will continue with NIST interaction.
  
- Continuing:
   Minimize number of req primitives
   FIPS compliance

- Open issue:

  Randomness source:
    Can we live with one of the sources contributing?
  Cipher selection: 
    Algorithm agility granularity
  Identity hiding
    We can probably defer
  Channel Binding 
    format and requirement for confidentiality

(Bernard): Do we need crypto to achieve CB?
(Yoshi): Q on CB? Which type of CB this WG is assuming?
  There is an issue about carrying CB over EAP method.
  It appears that some config of CB is needed at the server.
  Why do you need to carry CB info via EAP method?

(Hannes): We'll specify CB stuff separately, and not in EAP method.
(Joe): We determined that having the ability to carry channel binding type data,
  authenticated and possibly encrypted data,
  is a generic operation.
  Not sure if Exact format and contents are clear
(Jari): CB in EAP method and opaque

(Joe): Defining the format is hard: potentially there may be multiple
 types of data to carry. Method won't define the content of CB.  
 It's an opaque blob that a method carried.

(Yoshi): Why does CB info need to be carried in EAP method?

(Pasi): Different ways of doing CB.  One is to carry and that allows us
  to not modify APs.

(Hannes): We haven't really looked into Yoshi's latest document

(Joe): There are a number of reasons why you would carry it in EAP
  method. For example keying material may not be used in all circumstances.

(Bernard): Fix it in the EAP keying framework perhaps

(Vidya): About CB and using key derivation: when you tie that to key
  derivation would be too restrictive.  What if the peer's view of the
  CB is a subset of the AS's view of the CB

(Uri): I am not sure I agree.  Let's take it offline or to mailing list

===========================================================================
2. RFC2716bis-01 (Bernard Aboba)
===========================================================================

- <see slides>

- Next steps:
  Solicit feedback from implementers
  Moving forward?

- Volunteers for reviews:

Several Volunteers including:

  Uri (sort of interested)
  Vidya
  Pasi

 (???): Question about EMSK derivation and what about backward
  compatibility

(Hannes):  Do you support PSKs?
(Bernard): No, This is just based on certs

(Hannes): Request from 3GPP2 and WiMAX use PSKs.  What would they have
 to do if they want to do EAP-TLS-PSK.

(Bernard): What happens with backward compatibility. 
  Need empirical evidence. Certs are mandatory and PSKs would be optional, 
  so doesn't seem to add value.

(Hannes): Cleaner approach would be a new type code

(Bernard): agrees.

(Joe): Charter item on enhanced EAP-TLS (new type code) exists

===================================
End of scheduled agenda
===================================
Channel binding discussion
===================================

(Sam Hartman): EAP channel binding is binding to a specific port or NAS, is it?
(Joe): yes 

(Joe): channel binding carry two things: one for binding to a tunnel and one for
 Authenticator/NAS.  These are different types.

(Bernard): Has anyone implemented channel binding?

(no Answer)

(Joe): There is no need to do channel binding in many cases, since typically all authenticators in a system provide the same services.

(Bernard): One use case, is a discussion in 802.11u about monetary
verification

(Joe): differentiated AP case might need channel binding

(Pasi): two different types of authenticators providing different services