[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
authentication state capture
At the meeting, I questioned the design decision
of JFK to simplify by doing away with Main/Quick
modes in favor of a single exchange which always
reauthentictes. The problem that I brought up is
that it's not just rekeying which matters.
DELETE's, dead peer detection and restart
avalanches are also a concern. I also mentioned
that neither IKEv1/v2 or JFK deal with restart
avalanches very well.
I think there's middle ground here as demonstrated
by KINK. KINK has single round trip SA operations
which always use symmetric key authenticators,
even if initial authentication was done using
public key operations (eg PKINIT). Since KINK uses
Kerberos, it benefits from Kerberos' ticket
issuing mechanism which effectively captures the
public key initial authentication into a state
blob which the client holds, and can sign
authenticators against. This ability gives KINK
much better restart avalanche behavior since a
server/KDC going down does not require expensive
public key crypto to perform the authentication
phase again so long as a ticket is valid.
I think that SOI would be greatly facilitated by
taking a similar middle ground. I don't care
whether it uses Kerberos mechanisms as it's the
technique that's important, not the bit encoding.
Thus, I think there should be a requirement:
"The protocol MUST provide a facility to capture
expensive authentication operations into state
blobs created by the responder and held by the
initiator, which can be used in subsequent SOI
protocol operations such as rekeying, SA
maintenance, etc, and MUST be usable for a
configurable length of time even if the responder
loses state or reboots."
Mike