[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Summary of revised identity changes

Michael,

  Can you tell me how I initiate to another system based upon an e-mail
address? Remember, since we eliminated the mapping, you can't insert anything
that says:
     CN=kent@xxxxxxx	192.160.6.91

In the typical case for an individual in an enterprise setting (not in the opportunistic context), the individual is contacting the corporate IPsec server and that info is a local config parameter. That server would have a symbolic SPD entry for kent@xxxxxxx, and when the IKE exchange took place the current address for keent@xxxxxxx would be instantiated in the SAD and SPD cache, for use with future packets during the life of the SA.


  so, how do you set up *two* systems that can talk to each other?
Where are they? No, there is no configuration file, this proposal eliminates
the need for it.... it might be wrong.

I can't follow your text here, but the whole issue of how one uses symbolic entries for IP addresses in the SPD, and the translates them into specific IP addresses for the duration of an SA, is something that I hope to better describe in 2401bis, although the notion has always been in 2401.


    >> While that may be the desired effect for people with real PKI
    >> infrastructure and real PKI clue, for the people who just want to
    >> connect two LANs with a VPN, a self-signed certificate generated by
    >> openssl is *just fine*.
    >>
    >> If they have to get right goop in place to use certificates, even more
    >> people will want to continue using pre-shared keys.
    >>
    >> Now, if you, instead, are willing to say:
    >>
    >> All implementations MUST support RAW RSA key formats, providing a way
    >> to load/save them interactively (i.e. in a UI or CLI) in RFC3110
    >> format.
    >>
    >> Then, you can do whatever you want with certificates. But, up to this
    >> point, even doing self-signed X.509 (I wish they'd say "RFC2459"
    >> certificates) is hard for many products, and people therefore resort
    >> to pre-shared keys.
    >>
    Stephen> I too don't want to promote use of pre-shared keys. But, if I
    Stephen> have a RAW RSA format, what is the mechanism by which this
    Stephen> identifies me? It is not one of the ID types supported by the

  It identifies you because I said it did. Stop thinking about million node
VPNs for a minute.

I am accustomed to thinking about small PKIs, but I also want to make sure that the mechanisms we standardize scale well. I think what you are saying here is that the key identifies you only because someone built a table to map from the key to an ID. Asd I noted, there is no provision for IDs as IDs in the SPD in 2401, and I do not anticipate making such provision in 2401bis.

  Think about Bob's dinner's two franchises. He buys two D-Link IPsec/DSL
boxes. These are like ~$200 each. He hires some kid to hook them up into a
VPN. He plugs his Cisco IP phones in, and his cash registers in.

and what happens then? as many folks have noted for some time, its not hard to provide software that creates self-signed certs and exchange them for ID and authentication purposes. if you are going to have to go to the trouble of creating table entries to map big strings of bits (keys) as IDs, you could just as well perform the functions needed to use certs, including self-signed certs.



    Stephen> SPD. If you're saying that we need another mapping table from
    Stephen> key to ID, then I have the same concerns re getting this mapping
    Stephen> wrong.

Let's go back here a moment.

  If you make it hard, then people will use PSK. As such, you lose.
  If you want to kill public key use of IPsec with PKI, this proposal is a
way to do it. Go see EAP thread, cause we will need it.

We agree in principle, but I don't agree that any use of certs is as complex as your suggest. It seems to me that you are the one thinking in terms of very large PKIs and the complexity that accompanies them. Just because many IPsec vendors have chosen to use PKI software that was designed for large scale environments, and thus is overkill for the trivial context you describe above, does not mean that the problem is intrinsic in PKI. the different between public keys and self-signed certs is relatively small, but it allows more uniformity (and thus less complexity) for implementations that want to support both very small and larger populations.

Steve