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

Re: IKEv2 AUTH payload



Because of EAP, the AUTH payloads may appear in later messages, but they
always sign messages 1 and 2 of the INITIAL exchange.

I still haven't received any responses to my question of last week, about
what to do if the autentication exchange is repeated later on.  It appears
that in order to support this, I would have to store the old initial
exchanges so as to produce and verify the AUTH payloads, but that seems
wasteful.

Radia Perlman said:
> You're concerned about a recursion problem if the AUTH payload is signing
> the message in which the AUTH payload appears. However, the AUTH payload
> is signing a different message, so there isn't a problem.
>
> Alice (the initiator) is signing message 1, and her AUTH payload is in
> message 3.
> Bob is signing message 2 and his AUTH payload is in message 4.
>
> Radia
>
> ----- Original Message -----
> From: Kevin Li <kli@cisco.com>
> Date: Friday, April 9, 2004 7:39 pm
> Subject: IKEv2 AUTH payload
>
>> Hi,
>>
>> IKEv2-13 says that the entire IKE message (from the first octet to
>> last octet of
>> the paylod) will be signed. I am assuming that the AUTH payload is
>> not included
>> (even the nullified one -- all set to 0) for signature. It means
>> that the AUTH
>> payload will be the last one in the IKE message and message is
>> signed up to the
>> beggining of the AUTH payload.
>>
>> Is above the right interpretation? If so, it may be a good idea to
>> clarify this
>> in the spec.
>>
>> Thanks.
>>
>> Kevin
>> Cisco Systems
>>
>>
>>
>> ============= Quote from IKEv2-13 --- Start
>>
>> 2.15 Authentication of the IKE_SA
>>
>>
>>    When not using extended authentication (see section 2.16), the
>> peers    are authenticated by having each sign (or MAC using a
>> shared secret
>>    as the key) a block of data.  For the responder, the octets to be
>>    signed start with the first octet of the first SPI in the
>> header of
>>    the second message and end with the last octet of the last
>> payload in
>>    the second message.  Appended to this (for purposes of
>> computing the
>>    signature) are the initiator's nonce Ni (just the value, not the
>>    payload containing it), and the value prf(SK_ar,IDr') where
>> IDr' is
>>    the responder's ID payload excluding the fixed header. Note that
>>    neither the nonce Ni nor the value prf(SK_ar,IDr') are
>> transmitted.
>> ============ Quote from IKEv2-13 --- End
>>
>>
>
>