[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Naming 1: granularity
On Tue, 14 Feb 1995 smb@research.att.com wrote:
> Date: Tue, 14 Feb 95 09:22:24 EST
> From: smb@research.att.com
> To: ipsec@ans.net
>...
> The basic question is this: when we do a key management exchange -- and
> I realize that we haven't yet agreed on how to -- the two negotiators
> have to know names for the parties involved. In the case of two end hosts
> negotiating, the name should (but see the next message) refer to the
> hosts themselves. Should these names be IP addresses or domain names?
I don't think any one kind of name will satisfy everyone. Personally, I
believe we should emphasize domain names as much as possible. Certainly
if domain names are accepted, there is no need for iPv4 or IPv6 addresses,
as they have a simple mappiing into domain names via in-addr.arpa for
iPv4 and whatever is settled on for IPv6. There has always been a mapping
for user accounts into domain names, there is now a mapping for all the
world's telephone numbers into *.tpc.int, there is a draft out mapping
Autonomous System numbers into domain names, etc.
Still, there will be people who want a secure connection to an entity defined
only by its public key and there may even be people who will want to
communicate with an entity identified by a (shudder) Distinguished Name...
> But that's not the hard case. The hard case is when one party's
> cryptographic functions are performed by a crypto gateway, which protects
> a whole group of machines. Should this gateway use its own name? Then
> how does the remote end know it speaks for the real destination? Should
> the certificate for the crypto gateway contain a list of addresses? A
> list of address/mask pairs? A list of names? We cannot do gateway-to-host
> or gateway-to-gateway encryption till we settle these and related issues.
I think that, like they say, it depends. There will be gateway to gateway
cases which are essentially tunnels where the gateways have their own
name and just recongize each other and its transparent to everyone else.
There will be cases where a gateway tries to transparently act for a bunch
of machines and has keys to act for them all. If a gateway is for a
whole Class C net, then I guess its name could be *.x.y.z.in-addr.arpa.
Maybe this should be looked at operationally. If you try to send a packet
to host w.x.y.z and this gateway is in the way, you presumably get back
some sort of error. If the error says that, to talk to w.x.y.z (whose
name we will suppose is foo.bar.zz) you need to be secure to this gateway
then I guess the gateway could have any name. You might have a bit more
confidence if the gateway seems to be called x.t.z.in-addr.arpa or
perhaps bar.zz but, a long as you don't get any response from your
original packet, you might try being secure to this claimed
gateway even if its name seemed a bit odd...
If you were trying to communicate securly with a particular
host for NTP or routing or something else that is machine wide or
trying to communicate as a particular user account for ftp or something
that can depend on user identity and protections, then presumably you
had a key for the host or user entity you were trying to communciate with.
Either the gateway has that key aand everything looks great from your
point of view, or it doesn't in which case you can super-ipsec to the
gateway as well but I can't see why you would ever not use the correct
key for an ipsec to the end entity you really want.
> --Steve Bellovin
Donald
=====================================================================
Donald E. Eastlake 3rd 1-508-287-4877(tel) dee@cybercash.com
318 Acton Street 1-508-371-7148(fax) dee@world.std.com
Carlisle, MA 01741 USA
References: