[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No Subject
This is not to say that we shouldn't design and deploy quickly -- I
think Jeff Schiller made it clear we have very little time to
dilly-dally. However, I believe it is important not to chain ourselves
to Diffie-Hellman or any other specific technique.
> 2 questions.
>
> 1) Do you envision that there will be 2 methods (implicit and
> explicit) of key establishment?
I expect there will more than two, although I expect that there will
probably only be one popular one in the internet community at any one
time. I certainly expect that we will evolve to new techniques through
time and must set our structure up to permit that.
Steve Bellovin has noted that we cannot survive with too many options
-- interoperability will suffer. I fully agree with this. However, we
must recognise that what we do today and what we do tomorrow will not
be the same -- techniques WILL continue to evolve, and it would be
suicidal to chain ourselves to one particular set of algorithms.
> 2) If so, how do I determine the key management method?
I envision it being negotiated. The requester sends a capability
packet, and the responder selects (or some such.) This can be done in
an extremely simple manner -- it need not be a complex negotiation,
not even as complicated as that of Telnet.
> (Let me ponder the possibilities.... The SAID is indeed the -only-
> field other than the version that is defined. The SAID field is flat
> and has no meaning at this time.
That was what we more or less agreed on in the IPSP meeting, yes. The
negotiation between hosts is to determine the meaning of the field,
although implementations are free to try and play tricks, since the
receiver chooses the SAID.
The SAID is basically a selector for a security transform/key pair on
the receiver end. It has no meaning other than that which the receiver
has selected for ITS convenience.
> I guess that a value of 0 could mean implicit key exchange?
Actually, it makes far more sense to have it either be a reserved
value or mean the null security transformation (that is, pure IP in IP
or similar encapsulation, though I'm not sure what that would be
useful for.)
Having a reserved SAID value for a particular key management system
doesn't really make much sense, since the notion is that a SAID
indexes a particular transform, as I've noted, and not a key
management system. The SAID it isn't really related to key management
at all -- it is the partial output of the key management negotiation,
not an input.
> If you get a bad SAID, you could do implicit key management?
I think you can't avoid doing some negotiation, period. Why fear this?
Its not such a bad thing.
Perry