[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
minor Photuris changes
I spent the past day visiting NRL in DC with Atkinson and Schertler. We
were unable to come to closure on merging or making Photuris compatible
with ISAKMP.
There were minor changes we could agree upon.
1) Certificate TLVs need an authority field. Some of the certificate
types do not indicate their root inherently, and we need to be able
to choose among roots (for DNS-SIG and X.509). Some places (large
multi-national corporations) will not use or trust the basic DNS
tree. I was not aware of this, and need guidance as to the format.
Bellovin?
2) Expand the LifeTime field to 24 bits. Allows a key to live more
than a day. Seemingly far too long (in my view), but something that
they wouldn't reveal needs longer-lived keys. (I hate the secrecy.)
If you don't think this is much of a compromise, you should know
that the alternative was adding a length field to every timestamp to
allow completely variable time bases (as ISAKMP does). KISS.
3) Expand the Moduli Index cum Group Index to 16 bits. Rename as
Exchange Method (from ISAKMP) or something similar (Scheme?).
As you may recall, this was originally just a simple index for
moduli for modular exponentiation. Then, broadened to indicate the
"group" to allow use by other public-key techniques, such as
elliptical curves.
They claim that there will be thousands of proprietary (government)
key management schemes, which they want to indicate during cookie
exchange. So, we can reserve the first 256 for "well-known" values,
and leave the rest for "proprietary".
Again, I resisted making this a TLV, or having fixed subfields.
Flat numbering should work, as we only will require support for
_one_ value in this field. The others can certainly allocate as
many from their proprietary values as they like, since they will
have to distinguish themselves in some other way.
Also, they want to be able to indicate non-public key techniques.
This seems to violate the very principles of Photuris, which is
designed around public-key exchange.
My first inclination was to agree with Karn on this one. For
other keying variants, use another UDP port and another set of
messages. Trying to shoe-horn extra messages or more variable
values will make the actual key management process nearly impossible
to formally prove or verify.
We are already pushing the edge with variable moduli, variable key
generation method, variable signature methods, and completely
variable final security association attributes. There's 4!/2 (12)
combinations to verify already, assuming we use only D-H, MD5, DES
and PGP RSA as our verification base. It balloons rapidly.
However, Atkinson claims that it would be useful for the same
overall message exchange of security association parameters (what he
calls the SAMP) together with a KDC such as Kerberos. The public
value fields could be replaced with Kerberos tickets or something.
So, I agreed to expand this field to allow the attempt, as long as
we don't waste short term working group time and confusion exploring
the issue. If Ran doesn't actually come out with a Kerberos scheme
in two years, he owes me dinner....
Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2