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)
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|