[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Nodes and Users
> I'm noticing that each proposed secure protocol is reinventing the wheel
> regarding algorithms for public keys and formats for signatures. While
> I feel that certification is important, I'm uncertain as to how we wish
> to approach it. Certainly the PEM approach which specifies a standard
> certification hierarchy, etc., has not been successful. Meanwhile PGP
> certification has been more successful, albeit it is still a small fraction
> of the e-mail usage. I suspect that we will need a certification solution
> which allows both PGP style certification and a more hierachical form.
>
> Given all this what I'd like to see first is an RFC specifying a public key
> algorithm (PKCS#1 or PGP style internal formats using RSA or ElGamal, etc.)
> and signature formats (net order, ASN.1 and MIME formats). This allows this
> technology to be uniformly applied among all the other proposals. Future
> key distribution and certification RFC proposals will then have a good
> foundation to build on.
The syntax and certificate issues are important, but they're not what
I'm talking about. Here's the relevant passage from section B.1 of
Draft 5:
Identity-Choice
When selected as an Identity-Choice, the resulting Verification field
is 128-bits (18 octets including Size).
The Identification field contains a variable precision number that
identifies the party. Typically, the Identification is a Domain Name
or a user email address which contains a Domain Name.
In other words, we haven't agreed on what the endpoints are. This is
a serious matter. The reason this is so crucial is implied by the
following excerpt from Section 5.3:
Each party implements local policy that determines what access, if
any, is granted to the holder of a particular identity.
In other words, an IPSP end-system has to make authorization decisions
based on some string whose syntax and semantics are both unspecified.
Let's look at possible ways that IPSEC can be used. One is gateway-to-
gateway encryption, to support private virtual networks. In that case,
the (decrypted) IP address of the sender may be important for authorization.
But there is no specified format for ``list of IP addresses''. The closest
we come is a domain name, but that can only be used indirectly, and then
if and only if we're using DNSSEC. The Photuris draft says nothing about
DNSSEC, and the one reference to it in RFC 1825 refers to it for host
name keying.
We can also use IPSEC, and hence Photuris, for host-to-host encryption.
Again, the receiving system needs to know the IP address of its peer,
not just the domain name. For that matter, when the sender tries to
to do automated Photuris negotiation, it also wants a key tied to IP
address. But the user wants a key tied to the DNS name, since that's
the entity a user is dealing with.
Finally, IPSEC can be used for user-to-user encryption. This format
is properly supported by the Photuris mechanisms, but only because
the string user@domain can be treated as an opaque quantity. The
first two cases largely nullify the whole authentication mechanism
of Photuris, since in the final analysis -- that is, at the point where
one actually wants to make a decision based on identity -- there is no
real assurance of the identity of the other party. We may as well
fall back to straight Diffie-Hellman, since if we don't know to whom
we're talking, authentication matters little.
I don't have any pat answers for this. I suggest, though, that the
identity string be a 3-tuple of 0 or more usernames, 0 or more domain
names, and 0 or more IP address ranges. I'll leave the syntax and
certificate format issues to someone else... (I'll also note that even
this scheme doesn't work very well for IPv6, where the high-order
address bits aren't indicative of identity.)
Follow-Ups: