[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ipsec] Re: IKEv2 AUTH payload
That's about right.
Personally, I'd rather see the notification follow the IKE SA setup
with a number of seconds (we can call it REAUTHENTICATE_IN or
AUTH_LIFETIME), so that the client implementation can decide when to
initiate the new Initial exchange. If we send a REAUTHENTICATE_NOW,
the gateway has to estimate how long it would take the user to enter
the credentials. IMO this estimate is better left to client
implementors.
So:
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}
5. <- N(AUTH_LIFETIME(n))
6. ACK ->
<< Traffic goes on >>
<< After n - m minutes, the client notices that it
needs to do reauthentication now >>
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
And if the client does not know how to process the AUTH_LIFETIME
notification, we get afterm n seconds)
7b. <- D
8b. ACK ->
I agree that this can be added as a separate draft.
On Apr 19, 2004, at 10:08 AM, Tero Kivinen wrote:
> 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