[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ADMIN: Straw Poll Results on Key Mgmt
> From: Ran Atkinson <rja@cisco.com>
> 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.
>
I remember this one.
> (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.
>
I don't remember this one, and in fact, don't understand it. Each of
what components? Where did this requirement arise?
I have examined RFC-1825, and find the use of the word "component"
exactly once:
2. DESIGN OBJECTIVES
This section describes some of the design objectives of this security
architecture and its component mechanisms.
So, let us assume that the "components" are actually "mechanisms".
The next chapter of RFC-1825 specifies "mechanisms":
3. IP-LAYER SECURITY MECHANISMS
There are two cryptographic security mechanisms for IP. The first is
the Authentication Header which provides integrity and authentication
without confidentiality [Atk95a]. The second is the Encapsulating
Security Payload which always provides confidentiality, and
(depending on algorithm and mode) might also provide integrity and
authentication [Atk95b]. The two IP security mechanisms may be used
together or separately.
Thus, the "component mechanisms" are AH and ESP.
> % 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.
>
It couldn't have been unanimous, since I opposed it. Any Applicability
Statements belong in the documents themselves, as has long been the IETF
practice. Photuris contains an Applicability Statement.
> 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.
Well, since I don't know what you are talking about, perhaps you could
indicate exactly where Photuris doesn't meet some such requirement?
Are you saying that Photuris doesn't provide support for PFS, and/or
doesn't support AH and ESP?
You _have_ read the drafts, haven't you?
I call for the rest of the WG to bombard the chairs with their support
for Photuris. If it is found in the next few days to be lacking such
public WG support, I will instead publish immediately as Experimental,
pursuant to RFC-1602.
Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: