[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
architecture
My understanding of the most general architecture is that it goes something
like this:
application client
...
| \ \2
3| 1\ \ (SAID returned)
| \ \
| \ \
(said) (set security requirements description: service,
| | remote communicant id, alg (key alg))
| |
. .
. .
. .
ipsec key mgmt protocol
(lookup .
SAID- .
key .
assoc) .
. .
. .
network
In step 1, the application (or something near it) defines some
security requirements (authentication, privacy, etc.) or perhaps an
algorithm. The key negotiation is either specified as well, or it is
implied by the algorithm. A user id or other selection criteria might
be used to lookup appropriate originator public keys if needed.
Anyway, all the info needed for setting/getting the service key is
worked out by the key mgmt and associated with the SAID, which is
returned to the caller in step 2. The SAID is given to the transport
layers in step 3 as a sort of address extension when opening a
connection. IPSEC then uses the SAID to get the key and run the
crypto indicated by the SAID. Incoming messages are
decrypted/authenticated/validated/whitewashed based on the SAID.
As shown, this feels like a violation of layering to purists, and it
seems to me to be rational for some sites to have steps 1 and 2
performed by ipsec itself, using only the local and remote host
addresses for key related functions. I know that there is
disagreement on this point, which I respect, but it doesn't seem to me
that the ipsec or key mgmt protocols should try to enforce any
particular architecture or policy ... they should be minimal and
flexible.