Revised Identities (revised and revisited)

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

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


Ted sent out a plea for comments on some of these things.

>>>>> "Theodore" == Theodore Ts'o <tytso@mit.edu> writes:
    Theodore> 2)  Revised Identity
    Theodore> Paul Hoffman has a proposal which would replace the current methods of
    Theodore> identifying initiators and responders (i.e.):

    Theodore>       ID_IPV4_ADDR                        1
    Theodore>       ID_FQDN                             2
    Theodore>       ID_RFC822_ADDR                      3
    Theodore>       ID_IPV6_ADDR                        5
    Theodore>       ID_DER_ASN1_DN                      9  
    Theodore>       ID_DER_ASN1_GN                      10
    Theodore>       ID_KEY_ID                           11

    Theodore> with a completely different set of types:

    Theodore>         1  PKIX certificate
    Theodore>         2  Certificate bundle
    Theodore>         3  Hash-and-URL of PKIX certificate
    Theodore>         4  URL to a PKIX certificate bundle
    Theodore>         5  PKIX keyIdentifier
    Theodore>         6  IDForSharedSecret

    Theodore> This represents a fundamental shift in how IPSEC implementations handle
    Theodore> identities.  It has potential effects on how policies are looked up, and

  Only if left this way. There is an amended proposal.

  If you put the raw keys with DNS based identities that I suggested, 
  (see http://www.sandelman.ca/ipsec/2002/12/msg00250.html
  or   http://www.vpnc.org/ietf-ipsec/mail-archive/msg02834.html
  Hey, Paul, time to roll the VPNC list. It is 2003 now...)

  then there is no fundamental shift at all.

   ID_IPV4_ADDR	  -> identity from reverse map
   ID_FQDN        -> identity from forward map
   ID_RFC822_ADDR -> identity from forward map
   ID_IPV6_ADDR   -> identity from reverse map

    Theodore>       ID_DER_ASN1_DN                      9  
    Theodore>       ID_DER_ASN1_GN                      10
    Theodore>       ID_KEY_ID                           11

  These map to PKIX things.

  You are overstating this "shift" to a large degree.

  {Some may not want all of Me-Tarzan, You-Jane. I don't see how we can build
anything other than VPN gateways without it. We need this to be able to have
secure communication between multi-user systems that may have multiple
identities. We need it even for VPN gateways that expect to roll their keys
asynchronously from each other, and it lets one overlap certificate checking
and CRL download with RSA operations.}

    Theodore> To be fair, there are some arguments in favor of this proposal; by
    Theodore> forcing all implementations to use certificates as the basis of their
    Theodore> naming, it can solve a number of interoperability concerns.  (Although
    Theodore> on the other hand, the pki-profile document also solves many of these
    Theodore> issues without resorting to using an entirely new naming system.)

  No, I disgree. Forcing all implementations to use public keys may do this.
  Forcing everyone to use certificates means that IKEv1 will remain, and that
IKEv2 will never get deployed.

]       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

iQCVAwUBPkFJtoqHRg3pndX9AQHp3QQAqaq/B9CEqHORBm3X0zVYllJH+Otx/Nuo
Chz45nPSilz0k5fGhaHUe+ozHpC82dyqWrkAUcwbElkL0CwbD2pXf19PWaaXrkjG
bdk1CEFOOX2p3O2JzKae5b1HgjwSOJj2H8ws3MH53hG7f713BMjRyMuCXTBxrk7w
blBkcYj+/7A=
=gV7i
-----END PGP SIGNATURE-----