[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Clarification of EAP authentication in IKEv2?



Pasi, regarding the following issue vis-a-vis the text in 2.16:

>
>  For EAP methods that do not establish a shared key, the AUTH
>  payloads are calculated using (TO BE DETERMINED; see below).
>
[.......]
>
> 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).

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.

Thanks,

Hugo