[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ADMIN: Straw Poll Results on Key Mgmt
% Date: Thu, 4 Jan 1996 10:44:11 -0800
% From: Ran Atkinson <rja@cisco.com>
%
% 1) Can the IPsec WG produce multiple standards-track
% protocols for key management ?
The consensus is that multiple standards-track protocols can be produced
by the working group provided that there are significant differences
in applicability among the protocols. The most common example that
was mentioned was that multicast key distribution will probably need to
be a separate protocol than unicast key distribution.
% 2) If yes to the above, then can a protocol not conforming
% to the WG requirements for a key management protocol
% be on the IETF standards-track ?
The consensus is NO. All standards-track protocols MUST conform with
the IPsec WG requirements. As of now there are 2 main agreed-upon
requirements:
(1) Perfect Forward Secrecy (PFS) must be available to users of
the protocol that desire PFS. This means that a conforming
protocol might have a mode that provides PFS and another mode
that doesn't, for example.
(2) The key management protocol must be able to negotiate/
indicate the value of each of the components of an IPsec
Security Association (RFC-1825) with/to all of the parties to
that IPsec Security Association. Users are not necessarily
required to use all of those components, but the protocol MUST
be capable of providing that support and conforming implementations
of the protocol MUST support negotiation/indication of
all of those components.
% 3) If yes to both of the above, should the WG chairs write up a formal
% applicability statement to be accompany each standards-track
% key management protocol so that the intended use of that protocol
% is made clear?
There is overwhelming (possibly unanimous) consensus that the WG chairs
should be required to write up a formal applicability statement to accompany
each standards-track key management protocol so that the intended use of
that protocol is made clear in an RFC. Hence, the co-chairs will do this
if/when some protocol moves to standards-track RFC.
CONCLUSIONS:
(1) None of the proposals currently online appear to fully meet all
of the requirements, though it does appear that all of them could
be modified to meet all of the requirements.
(2) None of the current proposals can go to Last Call at this time
because of (1).
(3) All of the editors of the current documents should work on refining
their proposals to fully meet all of the WG requirements.
The co-chairs look forward to seeing revised proposals in LA.
In a situation like this one where the WG consensus is clear, the WG chairs
do not have any real discretion on handling matters. We are forbidden by
IETF standards process from doing anything contrary to WG consensus, so our
hands are completely tied on holding a Last Call at this time.
Paul Lambert <palamber@us.oracle.com>
Randall Atkinson <rja@inet.org>