Subject: Re: [Pana] Unique identifier per session

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 30 Dec 2003 11:11:18 -0800

> i tried to raise the same question with my text: is it necessary to
update
> the ike preshared secret with every re-authentication protocol run?
>
> we have multiple re-authentication procedures here:
>
> - PANA re-authentication
> - EAP full re-authentication (full run between the eap peer and the eap
> server)
> - EAP 'fast resume'
> - EAP run between the eap peer and the local aaa server (based on cached
> keys) (in some cases you could draw a relationship between 'fast resume'
> here.
>
> at the discussion in the eap keying design team i was not able to figure
out
> whether a fast resume actually produces new session keys.
>
> i would argue to update the PANA SA if an EAP run produces new keys. we
have
> to discuss how we can handle rekeying (i.e., where multiple PANA SAs are
> concurrently active) within PANA at least.
>
> hence, i would strongly argue against executing a new IKE exchange
wheneven
> you do one of these re-authentication steps. that would certainly hit
> performance and is not necessary and even the entrophy argument does not
> hold here since you can always create new IPsec SAs based on a quick mode
> exchange.
>
Agreed.

> a few comments on the ability to have multiple IKE pre-shared secrets
> currently for IKE protocol runs:
>
> ike does not support this type of scenario easily. as stated in
[ipsec-pana]
> in aggressive mode you could use the ID_KEY_ID with the (session id ||
> version number) as a key name. this would ensure that you always select
the

What do you mean by version number ?

> most recent key and in case of failures it would be possible to fallback
to
> the previous sa. however, this does not work with ike main mode
(pre-shared
> secret authentication) since the ID payload is sent after authentication
> (with message 5). this already caused problems in road warrior cases.
>
> from this point of view it would be good to use aggressive mode only (also
> from the number of messages). however, the availability of aggressive mode
> in existing implementations is not widespread.
>
My next update (soon to be out) already clarifies that only aggressive mode
 MUST be supported because of the problem you mention above with main-mode.

-mohan

> ciao
> hannes
>
>
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:[email-masked]]
> > Sent: Dienstag, 30. Dezember 2003 08:24
> > To: Mohan Parthasarathy
> > Cc: Yoshihiro Ohba; [email-masked]
> > Subject: Re: [Pana] Unique identifier per session
> >
> >
> > Hi Mohan,
> >
> > On Thu, Dec 18, 2003 at 03:00:28PM -0800, Mohan Parthasarathy wrote:
> > >
> > > > On Wed, Dec 17, 2003 at 09:02:09PM -0800, Mohan
> > Parthasarathy wrote:
> > > > > Hello,
> > > > >
> > > > > PANA session ID uniquely identifies a session. But, it also does
> > not
> > > change
> > > > > across a reauthentication.
> > > > > The PANA-IPsec draft needs something unique to identify the
> > pre-shared
> > > keys
> > > > > within a sub-session.
> > > > > Two possibilities.
> > > > >
> > > > > 1) During re-authentication, change the session ID also in
> > > reauth-answer.
> > > > > 2) Invent another ID that changes with every reauth and hence
> > uniquely
> > > > > identifies the keys derived
> > > > >     during a reauth.
> > > >
> > > > I think it does not make sense to change the PANA
> > Session-ID across
> > > > (re-)authentications just for this purpose.
> > > >
> > > > How about using <PANA Session-Id> | <N> as the IKE pre-shared key
> > > > identifier, where N is the number of EAP-based re-authentications
> > > > occured for the Session-ID?
> > > >
> > >  Can N go out of sync between the PAA and PaC ?
> > > I am assuming that "N" is implicitly and independently
> > arrived by PaC
> > and
> > > PAA.
> > >
> > > 1) PAA sends a reauth request
> > > 2) PaC sends a reauth answer and increments N by 1. This message is
> > lost.
> > > 3) PAA retransmits reauth request
> > > 4) PaC sends a reauth answer and increments N by 1. This message is
> > > successful.
> > > 5) PAA increments N by 1.
> >
> > Which type of "reauth" do you mean?  I am assuming that the
> > IKE pre-shared key is updated when an EAP-based
> > re-authentication occurs. When the other type of
> > reauthentication based on PANA-Reauth-Request/Answer exchange
> > occurs, I don't think the IKE pre-shared key needs to be
> > updated because there is no change in the EAP Master Session
> > Key in this case.  For EAP-based re-authentication,
> > synchronization on EAP Master Session Key derivation can be
> > made because PANA-Bind-Request that carries an EAP-Success
> > message is acknowledged with PANA-Bind-Answer message.
> >
> > Yoshihiro Ohba
> >
> >
> >
> > >
> > > As you can see, N is out of sync. Is the above possible ?
> > From what i
> > can
> > > understand
> > > about retransmissions (section 4.1.4 of PANA protocol), the above
> > looks
> > > possible.
> > >
> > >
> > > -mohan
> > >
> > > > Yoshihiro Ohba
> > > >
> > > >
> > > > >
> > > > > Any other possibilities ?
> > > > >
> > > > > -mohan
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Pana mailing list
> > > > > [email-masked]
> > > > > https://www1.ietf.org/mailman/listinfo/pana
> > > >
> > > > _______________________________________________
> > > > Pana mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/pana
> > >
> >
> > _______________________________________________
> > Pana mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pana
> >
>
>
> _______________________________________________
> Pana mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pana

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

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 30 Dec 2003 11:11:18 -0800

update
out
have
wheneven
Agreed.

[ipsec-pana]
the

to
(pre-shared

-mohan

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 31 Dec 2003 12:27:15 +0100

Hi mohan, 

please see my comments inline:

> From: Mohan Parthasarathy [mailto:[email-masked]] 
> Sent: Dienstag, 30. Dezember 2003 20:11
> To: Tschofenig Hannes
>   > i tried to raise the same question with my text: is it 
> necessary to update

if you have multiple IKE pre-shared secrets concurrently then you need to
have a way to distinguish a more recent key from an older one.
additionally you need to indicate this somehow. when entity A selects 
key X then entity B needs to know that X was selected. 

the key version number could be an integer which is increased by one if you
add a new version of the key.

> > from the number of messages). however, the availability of 
> aggressive
> mode
> My next update (soon to be out) already clarifies that only 
> aggressive mode  MUST be supported because of the problem you 
> mention above with main-mode.

great.

ciao
hannes

> > > Which type of "reauth" do you mean?  I am assuming that the IKE 
> > > pre-shared key is updated when an EAP-based re-authentication 
> > > occurs. When the other type of reauthentication based on 
> > > PANA-Reauth-Request/Answer exchange occurs, I don't think the IKE 
> > > pre-shared key needs to be updated because there is no 
> change in the 
> > > EAP Master Session Key in this case.  For EAP-based 
> > > re-authentication, synchronization on EAP Master Session Key 
> > > derivation can be made because PANA-Bind-Request that carries an 
> > > EAP-Success message is acknowledged with PANA-Bind-Answer message.
> > >
> > > Yoshihiro Ohba
> > >
> > >
> > >
> > > >
> > > > > > [email-masked] https://www1.ietf.org/mailman/listinfo/pana
> > > > >
> > > > > [email-masked] https://www1.ietf.org/mailman/listinfo/pana
> > > >
> > >

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 31 Dec 2003 12:27:15 +0100

Hi mohan, 

great.

ciao
hannes

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 31 Dec 2003 09:33:16 -0800

> add a new version of the key.
How do you propose to exchange this information between PAA and PaC ?
See the other discussion between me and Yoshihiro. Explicit communication
seems better. I think this should be another AVP. What do you think ?

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 31 Dec 2003 09:33:16 -0800

-mohan