[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Clarification of EAP authentication in IKEv2?
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