RE: Public Keys to initiate IPsec.

[Stephen Kent <kent@bbn.com>]

At 4:32 PM -0700 6/4/02, Michael Thomas wrote:
>Stephen Kent writes:
>  > This sounds like a problem re using IPsec. After establishing an SA,
>  > we check inbound traffic on the SA (from the peer) to make sure it is
>  > consistent with the parameters for the SA. We can check only the 5
>  > fields that are defined as traffic selectors. So, you could be
>  > spoofed by a peer who authenticates as one MGCP endpoint ID, then
>  > sends a message with a different MGCP name in the MCGP message. This
>  > is outside the realm of what IPsec can do for you. You would have to
>  > remember the MGCP name from the SA establishment for later
>  > application layer checking, and there is no standard interface that
>  > passes that info to your application.
>
>This is why I keep saying that it would be rilly,
>rilly nice to have this interface from the kernel
>(ideally, but could be with the keying daemon
>too). Nor do I see this as "outside" of what IPsec
>can do for you in the sense you seem to be using
>"outside". It's a missing feature on what my
>kernel/key daemon can do for me. There's nothing
>*wrong* with sending the credentials associated
>with a particular message up the stack.
>
>I'm just about ornery enough hack this into our
>Altiga shim just to prove it can be done and is --
>ta da -- useful for all of the reasons that Eric
>brought up.
>
>	Mike

Mike,

I used the term "outside" in two senses: First, the IPsec standards, 
like most of those in the IETF, focus on interoperability between 
systems, not on APIs within a system. Second, the checking that could 
be done if an API provided the authentication data is outside of the 
scope of IPsec, i.e., it has become the responsibility of the 
application.

I did not mean to suggest that there is no benefit to having this 
sort of API, just pointing out that APIs for IPsec are not currently 
within scope for the WG.

Steve