Re: [Ipsec] Re: IKEv2 AUTH payload

["Yoav Nir" <ynir@checkpoint.com>]

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.

Certificates don't have the same problem.  Certificates contain their
expiration time.  If a gateway is presented with a certificate that
expires in 5 minutes, it can set a timer to close the IKE SA in 5 minutes.
 Also, the client also knows about the expiration time, so it can know
when to re-authenticate and present a new certificate.  This is not
available when re-authentication is just a matter of policy.

Re-authentication is a requirement for many users.  If vendors can't
provide it as part of IKE, they will have to do so through other channels,
either a private notification or some kind of internal connection.  These
will be neither standard nor interoperable, and it would mean that when
using, say, a Microsoft client with a Cisco access concentrator, the
connection would break after some time.

In bakeoffs everything would be fine, because everyone would set the
re-authentication time to the maximum possible and there won't be any
disconnects.  In the field, these things will happen.

Geoffrey Huang said:
> Yoav Nir wrote:
>
>> It's a pity we haven't thought of it months ago.  I think there is a
>> general consensus that it is too late now to do anything so radical as
>> add new exchange types.
>>
>> I don't like the idea of the gateway triggering a new authentication
>> with a DELETE notification, because a delete notification requires the
>> client to delete all the child SAs.  If the EAP method requires the user
>> to enter a password (or the token card value) this means many seconds
>> without an IPSec SA.  That could kill an ongoing FTP, Telnet or mail
>> download.
>>
>> A better solution would be a notification within the original IKE_AUTH
>> exchange, where the gateway tells the client how long the authentication
>> is valid.  In essence, the gateway tells the client to re-authenticate
>> within 2 hours.  A properly designed client will ask the user for a
>> password 5 minutes before the deadline, and begin a new initial exchange
>> from scratch.  This way, the IKE and IPSec SAs can be replaced without a
>> loss of connectivity.  If the client does not re-authenticate in time,
>> then the gateway can send a delete notification.
>>
>> We could add an AUTH_LIFETIME notification (16395?) with 4 bytes of data
>> signifying the time (in seconds) before the authentication expires.  If
>> it's too late for it to enter the IKEv2 RFC, it can still be used as a
>> private notification.  In IKEv1 few configure an IKE SA lifetime shorter
>> than 2 hours.  Many extend it to 24 hours.  The worst interoperability
>> problem that could happen, is that clients abruptly disconnect after 2
>> hours.
>>
>> Does that sound reasonable?
>
> I don't think it does.  This idea of an AUTH_LIFETIME goes against the
> notion of
> enforcing an IKE lifetime as local policy.  I understand that the auth
> lifetime
> is slightly different from an IKE lifetime, but the difference is fairly
> nuanced.
>
> Nonetheless, if we do decide to have such a notification, I object to
> using a
> private value, as this would only add to interoperability issues.
>
> I'm not too familiar with the various user authentication methods, but do
> any of
> these methods support the notion of an authentication lifetime?
>
> Note that we'll have a similar problem with certificate lifetimes.  The
> way
> IKEv2 is currently written, an entity can present a certificate that
> expires in
> say, 5 minutes.  In the absence of another authentication exchange, the
> IKE
> peers could rekey indefinitely using the child SA exchange (even though
> the
> certificate is no longer valid).  In this case, as with the authentication
> lifetime, the implementation will have to enforce the certificate lifetime
> by
> deleting the SA(s) when the certificate validity expires.
>
> -g


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