| Conclusion of the eap-keying WGLC | <– Date –> <– Thread –> |
|
From: Jari Arkko (jari.arkko |
|
| Date: Sat, 24 Jun 2006 13:21:00 -0700 (PDT) | |
Based on my review of the mail threads, it seems that we have
concluded the discussion with the below issues, with suggested
text that is available from Bernard's issue list:
351 Incomplete EAP Pre-authentication discussion
352 Channel binding issue
353 Definition of Session-Id/Method-Id
354 Method-Id and Session-Id
355 Data Associated with Authentication
356 Ciphersuite independence and section 1.6.4
357 Channel binding definition
358 AAA-Key section 1.2
359 Typo, Section 1.4 editorial
360 EMSK transport
361 Child key expiry
363 Section 2.2 title
364 Section 2.1 AAA key caching
366 Section 2.2.2
368 Threat Model Assumptions
369 Key lifetime parameter removal
On the following issues the discussion was not yet
completed. Suggested next steps are included:
362 Lower layer params and EMSK
Here Vidya and Madjid disagreed, but there was
no followup. The disagreement may actually be
on text that is from RFC 3748, however. I talked to Bernard
and we can probably work out what to say so that you
Vidya and Madjid are OK with it. Expect an e-mail from
Bernard on this. In general, if there's future IETF work, such
as work possibly coming out of the HOKEY effort, it can
relax the rules from RFC 3748, just as RFC 3748 itself
says: "(This restriction will be relaxed in a future
document that specifies how the EMSK can be used.)"
365 Ambiguous use of identifier
It was unclear if Joe was OK with the final proposal.
Given that there was a fair bit of discussion about this,
I'd like to make sure that the end result was acceptable.
Joe?
367 Key scope and eap server auth
As above, pending Joe's response.
370 Key management
No discussion. Please comment.
--Jari (doing this on Bernard's behalf as he's one of the authors)
-
Conclusion of the eap-keying WGLC Jari Arkko, June 24 2006
- Re: Conclusion of the eap-keying WGLC Nakhjiri Madjid-MNAKHJI1, June 29 2006
Results generated by Tiger Technologies using MHonArc.