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

Re: DNS? was Key Management



 
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

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