Subject: RE: [Pana] Unique identifier per session

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 8 Jan 2004 16:21:49 +0100

hi mohan,

>  Hannes,
> 
> > hi mohan,
> > hi yoshi,
> >
> > i am also in favor of including information into the 
> PANA-Bind-Request 
> > message for this purpose. but i am still not sure whether 
> you need to
> update
> > the pre-shared secret for the ike run with every eap
> "reauthentication"
> > protocol run..
> Updating the pre-shared secret does not mean you negotiate a 
> new IKE/IPSec SA.

good. 

> It says that "in the future if you 
> negotiate new SA, use the new pre-shared key". What is the 
> problem with updating it everytime ?

adding a new pre-shared secret is no problem. but you need to specify
whether you run a new ike exchange as a result of a new eap exchange. i
guess in ieee 802.11i/8002.1x you establish a new link layer security
association if you execute a new eap exchange. 

is there someone who has a preference?
 
> 
> > instead i would argue that you should not do it.  using 
> this approach 
> > you could leave it to the network to trigger a change of the
> pre-shared
> > secret.
> >
> Do you mean a new message  ?

i personally think that you only need a new AVP which is carried within a
PANA-Bind-Request message. 

ciao
hannes

> 
> -mohan
> 
> 
> > ciao
> > hannes
> >
> >
> > > -----Original Message-----
> > > From: Mohan Parthasarathy [mailto:[email-masked]]
> > > Sent: Mittwoch, 31. Dezember 2003 18:33
> > > To: Tschofenig Hannes
> > > Cc: 'Yoshihiro Ohba'; [email-masked]
> > > Subject: Re: [Pana] Unique identifier per session
> > >
> > >
> > >  > >
> > > > > > 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 ?
> > > >
> > > > 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.
> > > >
> > > 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
> > >
> > > > >
> > > > > > 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.
> > > >
> > > > great.
> > > >
> > > > ciao
> > > > hannes
> > > >
> > > > >
> > > > > -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