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

Re: Clarification of EAP authentication in IKEv2?



Jari,

The concerns you express regarding the text in 2.15 and 2.16 are very
valid ones (regardless of the discussion about signature-less EAP
exchanges) and require some re-work by Charlie. See below.

>
> Having said this, the text in the draft does raise some questions
> that had no immediately obvious answers, at least not to me. Could
> be the heavy christmas food, but I wondered about the following:
>
> - Why does 2.15 say "when not using extended authentication" but
>  still 2.16 refers to 2.15?
>
indeed, a less confusing  text is needed

> - The beginning of 2.15, does it talk about only the *signature*
>  case, or is shared secret MAC case included? It does not make
>  sense to me that the two cases would sign different data, but
>  the formula for shared secret case in 2.15 does not include
>  the appended nonces and prf SK_a[ir]. Is this intentional?
>

Good point! I was assuming that <message octets> meant the data under the
signature, but re-reading this it really seems to point out to the first
and second msgs, respectively, in the protocol. This would leave the
nonces uncovered which is INSECURE. Therfore, the text regarding the
computation of AUTH in the case of shared-secret authentication should either
(1) explicitly add the nonces (as in the signature case) to the
data covered by the MAC in computating AUTH, or
(2) say that the data on which the MAC is computed (to create AUTH) is
the same as the data covered by the signature.
Note that these two specifications (1) and (2) are different: in (2)
prf(SK_a,ID) would be included under the MAC while in (1) it wouldn't.
If we assume that the shared secret is only shared between the specific
initiator and specific responder (which I hope is the case) then there is
no real need to add the identity (or its prf-ed value) in this case
(on the other hand, doing so for compatibility with the signature data,
has no harm).

> - What are the "message octets" defined in the 2.15 shared
>  secret case formula? Are they the same message octets and
>  additional data as is talked about in the above text? Or
>  different?

Yes, that is THE question. But I hope the above clarifies what the text
SHOULD (or MUST :) mean.

>
> > Therefore (and this is why I am cc-ing Charlie directly) we really need a
> > better text in 2.16.
>
> I agree.

and this time I even remembered to actually bother (i,e cc) charlie.

Hugo

>
> --Jari
>
>