Re: speaking of keys

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Stephen" == Stephen Kent <kent@bbn.com> writes:
    Stephen> I don't think we need an API here, although that might be nice long 
    Stephen> term. What we need is a set if MUSTs in IKE v2 that mandate the 

  Well, it is 2002, had you said "long term" in 1995, I'd agree. I think that
we have arrived where we need to be.

    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.

  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)

    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.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPgOCsIqHRg3pndX9AQEldwQAtC/3nRGKkPjo6Yb0Lcgf+0e28BkRQOJi
M0Cga72bGkj/cPEnx2E/OrpWswV4Jh5n7etXWd0Xo9W+hhw6S6n4IhbJ4W5XoPK+
5LTt7xD4yQSIkcwhNzhyX/+90rLH6sB/iYYc2AMUTFUiwKoZ/PpTGW53kgRMtgg2
Rn5C08LF1QU=
=rw1N
-----END PGP SIGNATURE-----