[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Internet Protocol Security Protocol (ipsec)
Bob:
>>The key management will be specified as an application layer protocol
>>that is independent of the lower layer security protocol.
>
>I can't help reading this to mean a new protocol. It is hard to believe
>we wouldn't want to use existing directory services such as the DNS.
>Actually a pet project of mine is to define X.509 using the DNS
>instead of X.500, but in such a way that you get exactly the same
>information whether you go through the DNS or X.500. This is not hard.
Yes, a new protocol is needed. Even if X.509 certificates are available in the
DNS dor Directory, a new protocol is needed. The IEEE 802.10 Working Group is
currently spending alot of time on this topic. When certificate-based key
management is used, there are four stages in key management for a lower layer
security protocol such as IPSP.
First, exchange certificates. This could be eliminated (or made optional) if
every entity in the network has a certificate posted in a globally available
DNS or Directory. Some algorithms for the generation of keying material
require some parameters that go along with the certificate. Different
parameters are used each time a key is generated, therefore the parameters
cannot be signed by the CA and made part of the certificate. Thus, depending
on the key generation algorithm, even if certificates are universally
available, then some information must be exchanged in this step. In the work
being done in IEEE 802.10, the two peers also exchange names for the key that
is generated at this stage.
Second, negotiate attributes. These attributes determine how the lower layer
security protocol (IPSP in our case) will use the key or keys. Will the key(s)
provide confidentiality, integrity, or both? Is a particular security label
associated with the key(s)? Perhaps the host implements more than one lower
layer security protocol. If so, the attribute negotiation will determine which
security protocol will be used with this key. In the work being done in IEEE
802.10, the attribute negotiation is protected using the key(s) generated in
the first stage.
Third, use the key. The lower layer security protocol (IPSP in our case) uses
the key to protect traffic (IP datagrams in our case).
Fourth, delete the key. One side tells the other that it is finished with the
key and it is deleting it. One side cannot be sure that the other will also
delete the key, butt can be assured that no more traffic will be exchanged by
the two hosts using that key.
In conclusion, posting X.509 certificates in the DNS and/or Directory does not
address all of the key management issues.
Russ
References: