[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: speaking of keys

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