Attached are draft minutes for IETF 65 EMU meeting. Please let me know
if you have any additions or corrections.
Thanks,
Joe
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
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
