Re: [IPsec] Draft: IKEv2/IPsec Context Definition

[Daniel Migault <[e-mail]>]

Hi Yaron,

Thanks for that useful input. I think you mention rfc6989 and
[http://cacr.uwaterloo.ca/techreports/2008/cacr2008-24.pdf]. We will
have a close look at them.

Actually it is not a bad thing to reduce the number of ways to express
keying information.

BR,

Daniel

On Thu, Mar 6, 2014 at 6:11 PM, Daniel Palomares
<[e-mail]> wrote:
> Hi Yaron,
>
> Thanks for the comments.
>
> Yeah, I have seen one application that implements High Availability by
> sending DH secret + KE + Nonces.
> Concerning the RFC that deals with the security issues resulting from this
> behavior, are you talking about  Yoav's RFC - IPsec Cluster Statement?. If
> not, could you please tell me which RFC are you mentioning?
>
>  So, as this is a known issue (Case #1), there is no problem to disallow it.
>
> Other point from previous discussions:
> I just wanted to add that in the Case #3, Valery and I had some offline
> discussions about it, and we found out that actually the SK_p*_old are not
> used to compute Session Resumption's AUTH payload. Instead, SK_d_old is used
> to compute it. This means that we actually can avoid SK_p*  to be included
> in the IKE_SA Context Parameters (with a Mandatory flag). If anyone thinks
> SK_p* might be needed for some other exchange, please point that out through
> the mailing-list.
>
> Thank you,
>
> Kind Regards,
> Daniel Palomares
>
>
>
> 2014-03-06 11:35 GMT+01:00 Yaron Sheffer <[e-mail]>:
>
>>> Sending SK_* is enough. Nonces are used only in calculations of SKEYSEED,
>>> SK_*, keymat for Child SA and AUTH payload content.Anyway, once the
>>> exchange
>>> is complete, the nonces, appeared in this exchange, may be discarded.
>>> Actually, you have 3 choices to exchange IKEv2 keying information
>>> between nodes in cluster:
>>> 1. Send your private DH key, peer's KE content and nonces. In this case
>>>      other nodes will recalculate all keys from the very beginning.
>>> 2. Send SKEYSEED and nonces.
>>> 3. Send computed SK_* keys. Note. that you even may omit sending SK_p*,
>>> as these
>>>      keys are used only during authentication (unless you implement
>>> Session Resumption,
>>>      but it also depends on how you store the tickets - by value or by
>>> reference).
>>> All approaches are equally possible. There seems to be some
>>> security and performance benefists for approach 3, but somebody
>>> may argue. Implementation may use any of this approaches
>>> and I don't think it's good to mandate the only approach,
>>> Regards,
>>> Valery.
>>>
>>
>> Actually, I would suggest that we disallow (or "deprecate") option #1.
>> IKEv2 explicitly allows for DH secrets to be shared between SAs (this is not
>> a good idea, but people do it for performance reasons), and we even have an
>> RFC to deal with the security issues resulting from this behavior. So a node
>> would be sharing more than it bargained for.
>>
>> Thanks,
>>         Yaron
>
>
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>



-- 
Daniel Migault
Orange Labs -- Security
[phone]