Re: Authentication methods in IKEv2

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Charlie" == Charlie Kaufman <Charlie_Kaufman@notesdev.ibm.com> writes:
    Charlie> At 11:45 AM +0300 11/11/02, Valery Smyslov wrote:
    >> I have some doubts about using of authentication methods in IKEv2.
    >> In IKEv2 negotiation of authentication methods was completely
    >> removed - each side simply uses his/her favourite method.
    >> I think this may lead to the lack of interoperability and extensibility
    >> in case one of the endpoints supports more than one method of
    >> authentication.

    Charlie> A problem only occurs when one or both sides have multiple different keys
    Charlie> (or different ways of using the keys) with which they could authenticate. I
    Charlie> would expect this case to be unusual, but it certainly could happen. If it

  The situation is not unusual.

  Any system that generates new public keys regularly will have multiple keys
that it could use. Combined with the fact that many directory systems are not
instantaeous, and you have a wave effect, that reminds me of how light/sound
propogates.

  Consider a system that wants to generate a new key every day. If you
combine that with a directory system that can cache, and that may take 6-12
hours to propogate changes to all places, then there is a problem to solve.
(DNS is like this, LDAP would be as well, but deployed LDAP doesn't replicate
or cache very well yet)

  So, on day 0, I generate a key K1, and I enter it into my directory via my "CA".
Nobody can see it yet, since it hasn't propogated yet, so I can't use it yet.

  On day 1, I start using key K1. Most sites can see it, and they cache it
for 24 hours. I generate key K2, which I enter into my directory, asking it
to expire K1 in 1 day.  I continue to initiate with K1.

  I may be able to mark K2 to be effective only on day 2, expiring before the
end of day 3. Depends upon my technology and how cooperative my CA is.

  Now, some sites (those very close to my directory primary), will see K2
immediately, but will see that they shouldn't use it. Some sites will have K1
in their cache, and won't see K2 until K1 expires from their cache.

  Now, at midnight on day 1 (is this local time, or GMT... are all the clocks
synchronized?), I start using K2, and I generate K3 as required. Some sites
won't have visited the directory yet, or may have even started negotiating 2
seconds before midnight. Now, I'm asked to authenticate... do I use K1 or K2?

  It depends upon what my peer thinks I should use. This is why it is
important for the initiator to specify what key/identity it thinks the responder
should use.

    >> For the rare case where the two endpoints don't really know each
    >> other *and* are going to trust each other *and* have multiple
    >> authentication mechanisms, we have eliminated a confusing option from
    >> IKEv1. That's exactly what IKEv2 was designed to do.

    Charlie> I might buy this. It is an uncommon circumstance. It will add
    Charlie> complexity to IKEv2 to handle it. If we decide to allow this, I

  It is non-existant in a single Enterprise VPN, which is the only major
deployment we have. So, to say it is uncommon is not useful here. It is
precisely the case of requiring interopability without pre-arrangement that
must push things here.

    >> need to be able to tell the 'client' that she's supposed to do legacy
    >> authentication (at least in my idea of how legacy authentication needs
    >> to work). So authentication-parameters for phase 1 need to be part of
    >> the SA payload in some way (as part of the cipher suite or as an extra
    >> value somewhere or whatever).

    Charlie> Yes, one of the issues with legacy authentication is how to negotiate
    Charlie> it in the case where it's one of several possible forms of authentication
    Charlie> an endpoint has "keys" for (again a fringe case). If we've going to
    Charlie> negotiate it, my preference would be to see it in an optional payload.

  I for one, am in favour of simplifying things by claiming that legacy
authentication is only ever used in a single direction, and only relevant to
enterprise VPN situations. As such, the "server", being the one with the
public key, should, if it is willing to do something, should be the one to 
indicate, within phase 1, what it can do. I think that EAP provides all of
this.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPgzdCIqHRg3pndX9AQEugAQA0RERjnU5wGYpszUusgyMNpfTRcjGKmsC
TJFH8H7kRvyYteZIB1qJIGf3smBCPT9q3bC9E/78tkAPymAELRW2udyZqugRdzLN
9RxgjEQnQ61MXhDcdPsVhBVo333YVRpZshiSvJkt+uyvefAvtq44zI5MlGq0rQR3
85KnTagcUtU=
=ang6
-----END PGP SIGNATURE-----