[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@bbn.com	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@bbn.com, and 
when the IKE exchange took place the current address for 
keent@bbn.com 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