[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Key Management, anyone?
> From: Steven Bellovin <smb@research.att.com>
>
> These are very valid points. Unfortunately, in my opinion DNSSEC
> is utterly mandatory for *any* type of key management for IPSEC.
>
> Suppose I want to establish a secure connection to plugh.com. My
> application -- say, telnet -- will ask the DNS for the IP address,
> and then do the socket() and the connect() operations. Deep in the
> bowels of the kernel, something in the protocol stack will realize
> that (a) the connection must be secure, and (b) it doesn't have a key.
> So it asks the key management daemon to negotiate a session key -- but
> the parameter passed via the PF_KEY interface *must* be the IP address,
> since that's all the kernel knows.
>
> You see where I'm heading. Without DNSSEC, there's an unauthenticated,
> security-critical step. I'll end up with a secure connection to an
> unknown party. Sure, the certificate for that party will identify
> them as bearhands.com, not plugh.com -- but I as a user will never see
> that certificate.
Are you saying that, despite the seesaws on user keying from
mandatory to recommended and now back to mandatory, you believe there is
*no hope of ever doing user-specific keying in IPSEC* ???
In other words, network stacks are not to be allowed to propogate user
context down to whatever layer the transform engine communicates with
the key management daemon, and key management daemons are not to be allowed
to contact the user or consult configuration files or caches or directory
servers other than DNSSEC to verify certificate names?
This is a critical point, because a community of users (such as the
DoD) can establish a certificate structure that it trusts to be correct,
but may (will :-) not be willing to trust a DNS directory service
administered by who knows whom.
It would be much better if DNS could be regarded much like SMTP - it
usually works as a transport mechanism to get bits from here to there,
especially if there is no benefit to attacking it. If users want email
security, they use MSP/PGP/SMIME/MOSS over SMTP and there's a good chance,
but no guarantee, that the message will get to its destination. If users
want connection security, they should be able to rely on DNS to give them
a shot at connecting to the desired destination machine, but it's up to the
key management daemons and ESP/AH transforms to ensure that the connection
is indeed secure, and that multiple users on one machine and multiple
servers on another can be cryptographically isolated.
If this isn't the direction IPSEC is heading, we'll have to abandon any
thought of using it, and stick with GSS-API or TLS mechanisms to achieve
the required connection security.
Follow-Ups: