[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ipsec] Re: IKEv2 AUTH payload



Yoav Nir writes:
> Some methods may, and the EAP-success message has optional text which
> could be something like "User authenticated for 7200 seconds".  But
> neither is generic enough.  The difference between re-keying and
> re-authentication is not nuanced, as re-keying can be initiated by either
> side, while re-authentication can only be initiated by the user.  OTOH it
> is the server (or gateway) that will have a policy about re-authenticating
> clients.  Unless the gateway passes the information to the client somehow,
> then there's no way that the client can authenticate in time.

So we need notification REAUTHENTICATE_NOW from the server (gateway)
to the client, which tells that re-authentication is required now. If
the client does not support that notification, and will not
re-authenticate in xxx seconds (configurable, default should be couple
of minutes) then the server will send delete notification to the IKE
SA, forcing the client to re-authenticate. If client does support
REAUTHENTICATE_NOW notifications it will start creating new IKE_SA
re-authenticating at the same time, and after that is finished, it
re-keys all IPsec SAs using that new IKE_SA with REKEY_SA
notification, moving all traffic from old SA to new. After the
re-authentication and rekey is finished, the client will delete the
old IKE_SA (and old IPsec SAs).

I.e. the protocol will be following (n = re-authenticate interval in
minutes, m = time to give for the client to finish the
re-authentication):


	Client				Server
	------				------

	<< Client will create initial IKE SA and IPsec SA >>

1.	HDR, SAi1, KEi, Ni ->
2.					<- HDR, SAr1, KEr, Nr
3.	HDR, SK { IDi, AUTH,
		  SAi2, TSi, TSr} ->
4.					<- HDR, SK { IDr, AUTH,
						     SAr2, TSi, TSr}


	<< Traffic goes on >>


	<< After n - m minutes, the server noticies that it will
	   require the client to do reauthentication now >>

5.					<- N(REAUTHENTICATE_NOW)
6.	ACK ->

	<< Client starts to create new IKE SA >>

7.	HDR, SAi1, KEi, Ni ->
8.					<- HDR, SAr1, KEr, Nr
9.	HDR, SK { IDi, AUTH,
		  N(REKEY_SA), SAi2,
		  TSi, TSr} ->
10.					<- HDR, SK { IDr, AUTH,
						     SAr2, TSi, TSr}

	<< Note, that client will send REKEY_SA notification along
	   with the IPsec SA creation. >>

	<< After the IKE and IPsec SAs are rekeyed, client will
	   delete old IKE SA, and the old IPsec SA (this is sent
	   inside the old IKE SA) >>

11.	D ->
12.					<- ACK


Now traffic has moved to the new IPsec SA, and the IKE SA has been
re-authenticated.

If the client does not support this new REAUTHENTICATE_NOW
notification the processing goes like this (after step 6):


	<< Client simply ignored the REAUTHENTICATE_NOW notification
	   as it didn't undestand it, or was unwilling (or unable,
	   because user didn't write in the password in time) to
	   re-authenticate now >>

	<< After m minutes the server decides, that the client is not
	   going to re-authenticate, so it simply deletes the IKE_SA >>

7b.					<- D
8b.	ACK ->

	<< Now client, will not have IKE_SA, nor IPsec SA, so it needs
	   to create them again when it needs them next (or when it is
	   again able to do it, i.e. when the user comes back from
	   lunch and is able to type in the password again >>

9b.	HDR, SAi1, KEi, Ni ->
10b.					<- HDR, SAr1, KEr, Nr
11b.	HDR, SK { IDi, AUTH,
		  SAi2, TSi, TSr} ->
12b.					<- HDR, SK { IDr, AUTH,
						     SAr2, TSi, TSr}

	<< Traffic can continue >>

That kind of change can be made after the base IKEv2 draft is ready,
as a separate draft and protocol, as it will be interoperable with
base IKEv2 version too.
-- 
kivinen@safenet-inc.com

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec