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

From: Giaretta Gerardo <[email-masked]>
Date: Wed, 03 Nov 2004 15:14:47 +0100

Hi Mohan

see below...
> 
> - section 5, paragraph regarding the Key-ID: the draft states 
> that "during the lifetime of the PANA session, there could be multiple
> EAP re-authentications". Does it mean that the PANA session 
> lifetime can be greater than the AAA-key lifetime? It seems to me that
> PANA draft is not clear on that. (Probably this is a PANA 
> draft issue, not a PANA-IPsec one). PANA draft states that 
> PANA session
> lifetime is equal to PANA SA lifetime. If PANA session 
> lifetime can be greater than AAA-key lifetime, I think that 
> the AAA-key
> lifetime (or at least the lifetime of PANA_MAC_KEY) should be 
> part also of the PANA session attributes. This is particular useful in
> the mobility handling case, since the new PAA has not 
> performed any EAP authentication and therefore does not know 
> anything about
> the lifetime of the AAA-key (or the AAA-key-new).
> 
> mohan>> I will wait for the resolution on the PANA draft and 
> reflect the same here.
> 

Agree

> - section 5, last paragraph. The draft states that if IPsec 
> SA lifetime expires, the re-negotiation must use the new 
> pre-shared key.
> In this case, I wonder whether IKE SA should also be 
> re-negotiated, even though its lifetime has not expired yet. 
> Otherwise the IKE
> SA depends on a PSK (the old one) and the IPsec SA on another 
> (the new one). I think the draft should be clearer on this. In
> particular there are three possibilities when the PSK changes:
> 
>      o when the IPsec SA lifetime expires, both IKE SA and 
> IPsec SA are re-negotiated with the new PSK;
> 
>      o when the IPsec SA lifetime expires, the IPsec SA is 
> re-negotiated using the old key. Only when IKE SA expires, 
> both SAs are
> re-negotiated with the new key;
> 
>      o when the IPsec SA lifetime expires, the IPsec SA is 
> re-negotiated using the new key (the IKE SA is not re-negotiated). If
> I've understood correctly, this is the case of the draft.
> 
> mohan> In the draft, it says:
> 
>            During EAP re-authentication, the AAA-key changes. 
> Whenever the AAA-
>             key changes, a new value of Key-ID is established 
> between the PaC and
>            PAA/EP as defined in [PANA-PROT]. If there is 
> already an IKE SA or
>            IPsec SA established, it MUST continue to be used 
> till it expires. A
>           change in the value of AAA-key MUST NOT result in 
> re-negotiating a
>           new IKE SA or IPsec SA immediately. But any new 
> negotiation of IKE SA
>          or IPsec SA MUST use the new pre-shared key derived 
> from the latest
>          AAA-key and is indicated by the Key-ID in the above equation.
> 
> 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.  

> 
> - maybe something about the key defined in the document and 
> its lifetime might be mentioned in the Security 
> Considerations section.
> BTW, does the IKE Pre-shared key derived from PANA have a lifetime?
> 
> mohan> Good question. Old IKE PSK dies as soon as the AAA-key 
> changes, though the IKE SA and IPsec SA
>               continues to live on till its expiry. We can 
> mention this in the Security considerations section.
> 

Agreed

--Gerardo

> 
> Regards,
> 
> --Gerardo
> 
> -mohan
> 
> 
> 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
> ====================================================================
> 
> 

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

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 4 Oct 2004 11:00:25 -0700

Agree

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.

Agreed

--Gerardo
-mohan