John, >However, IPSEC only authenticates to IP addresses. You are wrong. IPsec provides authentication to the "owner" of the security association. This security association may be bound to one or more IP addresses, one or more DNS names, or some other named entity (like a PGP key). The implementations that you choose to field may be limited to provided IP addresses as an authentication "handle". >Even if usernames or hostnames >are used in generating keys, there's no well-defined >way to get that information back to an application; >all it has is getpeername(). Getting the name from a IPsec security association to an application is a "local issue". Some operating systems and application will not be able to support this capability. This should not prevent the access control decisions that are enforced at the network layer from being tied to a useful user oriented identity. For example, consider a dial-in host (with IPsec) connecting throught the internet to a firewall (with IPsec). The IP address for the remote host is not a useful identification mechanism since it changes. A PGP name and key would be much more useful as an entry in a Access Control List (ACL). I am not strongly advocating PGP as a certificate infrastrucuter for IPsec, but am surprized that implementations have not surfaced using this technology. >If dynamically assigned >IP addresses are easy, throw 'em in; if not, >leave them for the next round of standards. Since >everyone seems to think they're hard, let's leave >them for next time, and secure the large fraction of >the Internet that we know how to do now. Everyone? Dynamically assigned IP adresses are not a big problem for IPsec and vendors on this list already have implementions that support this feature. In our rush to field public domain code we should not throw out useful features. Paul -------------------------------------------------------------- Paul Lambert Director of Security Products Oracle Corporation Phone: (415) 506-0370 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963 Redwood Shores, CA 94065 palamber@us.oracle.com !!! Still hiring, send resumes to: palamber@us.oracle.com !!! --------------------------------------------------------------
-- BEGIN included message
- To: ipsec@tis.com,gnu@toad.com
- Subject: Re: DNS? was Key Management
- From: "John Gilmore <gnu@toad.com>" <ipsec-request@neptune.hq.tis.com>
- Date: 14 Aug 96 16:55:59
- Sender: ipsec-approval@neptune.hq.tis.com
One of the problems that has hung up all sorts of crypto protocols is getting confused about what problem you are trying to solve. Like PEM, let's not define all the packet formats and then spend three years arguing over who authenticates what to who. > Then the minimal basis for authentication is the association of a public key > with an e-mail address, a hostname, or an IP address that can be used to > support access control decisions. DNSSEC supports associating a public key (or several public keys) with each of the above. IP addresses are encoded into the domain-name space in the usual 1.2.174.140.in-addr.arpa way. Email addresses are encoded as e.g. gnu.toad.com by setting a bit in the KEY record which indicates that the first component refers to a user rather than to a host or subdomain. However, IPSEC only authenticates to IP addresses. There's no further identification in the IPSEC packets. Even if usernames or hostnames are used in generating keys, there's no well-defined way to get that information back to an application; all it has is getpeername(). > Is it sufficient to say that authentication is based on an e-mail address > (personal), hostname, OR an IP address (network entrypoint)? Then the > application/service which is accepting the authenticated identity must > determine if this binding is sufficient authentication for the particular > activity/access/application? I believe you meant "sufficient authorization". IPSEC and DNSEEC do not solve this second problem (applications deciding whether to accept authenticated identities). That's an access control question (is he allowed?) as opposed to an identity question (who is he?). IPSEC doesn't solve the global "single signon" problem; don't expect it to. I may supply information to authenticate myself to other parts of the network, and a firewall somewhere may use this information to decide whether to let my packets in the door. But IPSEC running at FOO.COM should be willing to build an encrypted tunnel to my laptop, whether or not my laptop later ends up authenticated as "the laptop that FOO.COM's system administrator borrowed while he was at a conference". I also think we should focus on shipping standards that hit the sweet spot (most gain for least pain), which includes securing communications among all the hosts with fixed IP addresses. If dynamically assigned IP addresses are easy, throw 'em in; if not, leave them for the next round of standards. Since everyone seems to think they're hard, let's leave them for next time, and secure the large fraction of the Internet that we know how to do now. John Gilmore
-- END included message