RE: Clarification of EAP authentication in IKEv2?

[Hugo Krawczyk <hugo@ee.technion.ac.il>]

thanks Pasi for the clarification.
In light of what you say below we have a few choices on how to proceed:

(1) leave things as they are now, using SK_a as a key to the prf as currently
    specified in sec 2.15, and also as a key to prf in the planned new
    text of 2.16 for computing AUTH (by the initiator in msg 3) in the case of
    EAP methods that do NOT generate keys

(2) change the spec to use the integrity algorithm from SK{} (i.e. type 3)
    instead of prf in the above cases

(3) derive an additional pair of keys from SKEYSEED (call them SK_pi and
    SK_pr) for keying the prf in these two cases.

The first option is the simplest now but wrong from the crypto point of
view as it violates the basic principle of not using the same keys with
different algorithms.
The second solution is simple as it only requires a small change in the
spec language and no implementation difficulty, EXCEPT that if we envision
the use of "authenticated encryption" transforms for ESP (and then for
SK{} too) then the notion of "the integrity algorithm" used in SK{} may
not be well defined (some authenticated-encryption transforms will not
define a stand-alone integrity algorithm).

The last option is the rightest one, cryptographically speaking, but it
requires one more pair of keys derived from SKEYSEED. No big deal (though
I can feel Charlie's resistance to it :)

I guess that it is for Charlie to decide (my vote is obviously for 3)

Hugo

On Wed, 31 Dec 2003 Pasi.Eronen@nokia.com wrote:

>
> Hugo Krawczyk wrote:
> >
> > > I left the case on non-key-generating EAP methods open,
> > > since while your proposal for using SK_ai/SK_ar looks good,
> > > how do we actually ensure that the algorithm is the same as
> > > used for integrity within the SK{} construct? They're negotiated
> > > separately... would using some public-but-random value like
> > > prf(Ni|Nr,"EAP") be ok, or do we need to derive one more key
> > > from SKEYSEED?
> > >
> >
> > If I understand correctly there are two different
> > integrity-type transforms (based on the transform types in sec
> > 3.3.2): type #2 is prf (which I believe is the function used
> > for key derivation and referred to as "prf" in the text,
> > e.g. in sections 2.13 and 2.17) and type #3 is an integrity
> > algorithm which (I guess) is the one used BOTH for the MAC
> > function that is part of SK{} AND the MAC function used to
> > generate AUTH in the case of shared-secret authentication (and
> > EAP).Is this interpretation correct?
> >
> > If so, then AUTH and SK{} use the same integrity algorithm
> > (type #3) and the problem you point out to is solved. If they
> > are different, then please explain where in the spec they are
> > treated differently (in particular for negotiation purposes).
>
> My understanding from Section 2.15 is that transform type #2
> ("prf") is also used to calculate the AUTH payload for shared
> secrets (and EAP):
>
> In the case of a pre-shared key, the AUTH value is computed as:
> AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <message octets>)
>
> This would mean that transform type #3 is used only for SK{},
> right?
>
> > Now, if the above interpretation is correct then I may have a
> > problem with the use of SK_a under the prf as specified in
> > 2.15. But please answer my question above before we proceed to
> > finally clarify these issues.
>
> Assuming that "prf(..)" in Section 2.15 refers to transform
> type #2 (as it does elsewhere in the document), and that
> SK_a is used with type #3 in SK{}, there indeed seems to be
> a possibility for using the same key with two different
> algorithms...
>
> (However, the values prf(SK_ar,IDr') and prf(SK_ai,IDi')
> are never transmitted, so I don't know how serious this is.)
>
> Best regards,
> Pasi
>