Subject: RE: [Pana] RE: Review of draft-ietf-pana-ipsec-04

From: Giaretta Gerardo <[email-masked]>
Date: Fri, 05 Nov 2004 14:17:05 +0100

Mohan,

as you mention there are two possibilities:

1. when the IPsec SA expires, the IPsec SA is re-negotiated using the
old PSK. Only when IKE SA expires, both SAs are re-negotiated with the
new PSK;

2. when the IPsec SA lifetime expires, both IKE SA and IPsec SA are
re-negotiated with the new PSK;
 
I'd prefer the first solution in order to avoid unnecessary IKE
re-negotiation, but I'm ok also with solution 2.

--Gerardo

> -----Original Message-----
> From: Mohan Parthasarathy [mailto:[email-masked]] 
> Sent: Tuesday, October 05, 2004 9:32 PM
> To: Giaretta Gerardo
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Pana] RE: Review of draft-ietf-pana-ipsec-04
> 
> 
> Giaretta,
> 
> Yes, there is some confusion in the draft that can be 
> clarified. A new value of IKE PSK does
> not directly affect the new IPsec SA negotiation. Hence, any 
> new IPSec SA negotiation
> after the new IKE PSK is derived, will still use the old PSK 
> only. So, we have to negotiate both
> SAs in one shot when either of them expires so that new PSK 
> will be used OR use the new
> PSK only when IKE SA expires which would need the 
> implementation to remember
> both PSKs for sometime.
> 
> -mohan
> 
> ----- Original Message ----- 
> From: "Giaretta Gerardo" <[email-masked]>
> To: "Mohan Parthasarathy" <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Thursday, November 04, 2004 3:06 AM
> Subject: [Pana] RE: Review of draft-ietf-pana-ipsec-04
> 
> 
> Hi Mohan,
> 
> please see below..
> 
> 
> > > The last sentence says that only new negotitations of IKE SA 
> > > and IPsec SA should
> > > use new pre-shared key. If we don't want to maintain two or 
> > > more pre-shared keys,
> > > it might make sense to re-negotiate both SAs at the same 
> > > time. But normally IKE SA
> > > lifetime and IPsec SA lifetime are configured differently and 
> > > they expire differently.
> > > So, don't know whether it makes sense to tie them or not.
> > > 
> > 
> > My prime concern was about possible security implications 
> in the case
> > where you would use the new pre-shared key directly to derive 
> > the IPsec
> > SA, without first performing an IKE Phase 1 (at least, this 
> > is what the
> > "or" in that sentence seems to suggest). It is not clear to 
> > me how this
> > is done without first running Phase 1, nor I think this would 
> > be the way
> > to do in IKE. Hopefully somebody more familiar with IKE than me will
> > comment on this.  
> > 
> > mohan> Getting a new IPsec SA without re-negotiating a IKE SA means,
> > running just phase II in IKEv1 and running CREATE_CHILD_SA in
> > IKEv2.
> >
> 
> Sorry, but it is not so obvious to me.
> 
> In the case of IKEv1, Phase 2 uses hashes keyed with a key that is
> derived from the pre-shared key as a result of Phase 1 
> negotiation (e.g.
> SKEID and SKEID_a). How do you intend to derive this key 
> performing only
> Phase 2 with the new pre-shared key? 
> If you look into the IKE spec, the pre-shared key is input in Phase 1
> and then a chain of keys are derived (incl. the one for Phase 
> 2), using
> info from Phase 1. 
> Maybe I'm missing something and there are no issues here, but I think
> that the draft should detail better on this re-negotiation. 
> 
> We can talk next week about this.
> 
> --Gerardo
> 
> 
> Gruppo Telecom Italia - Direzione e coordinamento di Telecom 
> Italia S.p.A.
> 
> ====================================================================
> CONFIDENTIALITY NOTICE
> This message and its attachments are addressed solely to the persons
> above and may contain confidential information. If you have received
> the message in error, be informed that any use of the content hereof
> is prohibited. Please return it immediately to the sender and delete
> the message. Should you have any questions, please send an e_mail to
> [email-masked]. Thank you
> ====================================================================
> 
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pana
> 

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana