[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: >Draft Charter IPSEC WG



        Reply to:   RE>>Draft Charter IPSEC WG

There have been numerous comments suggesting that Rkey managementS be
removed from IPSEC.  As one of the authors of the draft charter I would like
to explain and defend the inclusion of the key management tasks.  

>Given the ongoing work in CAT and PEM has significant key management
>aspects, I wonder if a separate WG might be a good place to develop a
>key management protocol that is already proposed to live in the
>application layer?  I would hate to see the network layer focus of
>this WG cause a key management protocol to arise which might be too
>layer 3-centric.  Of course close co-ordination would need to be
>maintained between two the WGs if a separate KM WG was formed, to
>ensure that the resulting protoco, adequately supports the
>requirements of a layer 3 security protocol.
>
>Steve

and...

>Why not setup a parallel WG to work on the key mgmt aspects
>while the IP Security WG works on the authentication/confidentiality
>mechanisms for IP ??
>
>Ran

Considerable discussion of key management went into the creation of the
schedule and milestones for IPSEC.  The intent was to ensure that the
milestones included a "complete" and workable "ip security" solution. 
Relying on another, yet to be formed group did not seem to be a viable plan.

The base work for Rnetwork securityS is quite mature and the March 93
milestone for a draft of this specification is reasonable.  Most of this
work has had little visibility in the Internet community, but has been
extensively  documented (as SP3 and NLSP).  At least five commercial
implementations (non-interoperable) have been fielded.  The SP3/NLSP
security is quite straightforward for host-to-host implementations.

March 93 was also set as a milestone for selecting a direction for key
management that would support the lower layer security mechanism.  Perhaps
the text in the charter for an:
R      Initial framework for Internet key management techniquesS
is phrased in too broad of terms.  This might have been phrased better to -
define the requirements and select an initial approach to provide key
management for ipsec  The area of key management is also a well worked, but
immature technical area.  The related existing work includes:  IEEE 802.10C,
ISO GULS, IETF CAT, SNMP, SDNS KMP, and ANSI X9.xx.  The intent was not to
reinvent, but to hopefully adopt , adapt, or build upon existing work. 

After the definition of the simplier host-to-host signaling, the
subnet-to-subnet issues will be confronted.  I feel that it is critical that
a single working group investigate both key management and the network layer
issues.  Many of the possible solutions for the interesting subnet security
issues are provided by a close coupling with key management. 

The final milestones include the development of prototypes for
subnet-to-subnet security mechanisms.  Interoperabilty can only be
guarenteed if both the lower layer protocol and key management signaling
interoperate.

Rather than prematurely restraining the working group I suggest that we
proceed with discussions of key management requirements for ipsec within
this forum.

Paul