RE: Re: Issue 267: PRF Negotiation
From: Joseph Salowey (jsaloweycisco.com)
Date: Sun, 24 Oct 2004 23:51:52 -0400 (EDT)
Yup, sounds like it is a good idea. How about the following:

Create an IANA managed list (expert review) of PRFs that have the
appropriate form.
Assign one of the PRFs as the default PRF.
If an EAP method specification doesn't specify anything then the default PRF
is used.
As an alternative, an EAP method specification may either specify an
alternate PRF from the list or it may provide a way to negotiate one of the
PRF's in the list. 

If this sounds good I can write it up more formally.

Joe


eap-admin [at] frascone.com wrote:
> I agree that this is needed.  The issue of PRF negotiation
> has come up recently with respect to the NIST analysis of 802.11i.
> 
> Can you suggest some text?
> 
> On Tue, 19 Oct 2004, Bernard Aboba wrote:
> 
>> Issue 267: PRF Negotiation
>> Submitter name: Florent Bersani
>> Submitter email address: florent.bersani [at] rd.francetelecom.fr
>> Date first submitted: 10/2/2004
>> Reference:
>> Document: Keying-03
>> Comment type: T
>> Priority: S
>> Section: Appendix F
>> Rationale/Explanation of issue
>> Appendix F.1
>> 
>> IIRC we had a discussion whether the prf used to derive AMSK should
>> be mandated or could be negotiated
>> 
> (http://mail.frascone.com/pipermail/eap/2004-March/002384.html
> ). There
>> is a trade off between the two options (simplicity & interoperability
>> are in favor of mandating one but not putting a mandatory requirement
>> on peers and servers favors allowing negotiation). This is not
>> reflected in the current appendix. I'd like some more discussion on
>> the matter.... 
>> 
>> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap


Results generated by Tiger Technologies using MHonArc.