Re: speaking of keys

[Stephen Kent <kent@bbn.com>]

Michael,

<SNIP>
>
>     Stephen> provision of (local?) management controls over the 
>specification of
>     Stephen> DH groups, not just the ones already specified. We have 
>provisions in
>     Stephen> IKE for passing group parameters, but I have been told 
>that they are
>     Stephen> not generally supported, and thus rarely if ever used. For my
>     Stephen> purposes, I would be happy with a way for a community 
>to specify the
>     Stephen> parameters and inserts them into all of the community members'
>     Stephen> systems via a management interface, and then use a 
>locally managed
>     Stephen> (but globally unique) ID, e.g., an OID, to refer to the 
>parameters.
>
>   That's a lot of words that you want to use instead of the words "API"!
>
>   Remember that we got into this discussion because some people feel that DH
>groups larger than 1024 might be "too slow" for their application. Right now,
>this is up to the admins of the gateway boxes. As we move towards host IPsec
>(I run a *LOT* of /32<->/32 tunnels now), it becomes more and more necessary
>for applications to be able specify what they want.

An important feature of IPsec is that an administrator can impose 
security controls on traffic without having to rely on individual 
applications to be able to make these choices, and without having to 
worry that a Trojan Horse has tampered with an application to disable 
security controls.

I agree that under some circumstances an application could make these 
choices, but there are lots of circumstances where this would delay 
use of Ipsec (because the apps are not security-aware) or could lead 
to vulnerabilities due to TH problems of the sort I mention. So, 
whole I am not opposed to work on an API for IPsec management, I do 
not believe it is a prerequisite for the sort of function I am 
suggesting, i.e., a local management capability to select (possibly 
private) DH groups. We can mandate such a capability for IPsec 
implementations without specifying HOW the capability is provided. 
Also, if you want to develop an API, that would not conflict with the 
mandate capability requirement.


>   The details - like you need 1535 bit DH groups to properly key AES-128, is
>*NOT* something I want the applications people to concern themselves with.
>(by this, I mean those people in WGs that fall into "APP" categories. They
>want to be able to say "Just use IPsec", and we want them to, but we probably
>need them to say IPsec(X,Y,Z) and definitions of X,Y,Z should be as simple as
>possible)

we agree on these points.

>
>     Stephen> However, I realize that this would not be supportive of the
>     Stephen> opportunistic encryption model you have proposed, so maybe this
>     Stephen> approach is not sufficient for all.
>
>   Remember that there are three issues here, that are very seperate.
>
>   1) what is the MUST in the document.
>   2) how does an application that wants deviate from the norm indicate this
>      to IKE?
>   3) how does an administrator that wants to deviate from the norm indicate
>      this in their management interface.
>
>   You want #3, that's fine. You need to first define this common management
>interface --- sounds like IPSP work to me.
>

I am not opposed to facilities that support #2, I just think they are 
less critical than #1 & #3, and, as I noted above, I am willing to 
reword my request to say that it would be satisfied by a suitable 
implementation of #2.

For example, I assume that even if we have an API that apps can use 
to specify controls, that you would want some defaults and one way of 
configuring the defaults is via an administrator interface. Would 
that satisfy your goals?

Steve