RE: Requirements for IPsec Application

Please excuse the intro "Gentlemen" used below, as I know we have a wide
participant base and audience. (the email started as a draft to just a few
individuals). I should have replaced it with "Folks," before sending.
 
My apologies to our female colleagues.
 

-----Original Message-----
From: Gregory Lebovitz [mailto:Gregory@netscreen.com]
Sent: Tuesday, May 28, 2002 3:00 PM
To: 'www-xkms@w3.org'
Subject: Requirements for IPsec Application


Gentleman,
At the urging of both Stephen Farrell and Thomas Hardjono I am submitting
the attached requirements draft to this XKMS mail list for consideration
into the XKMS body of requirements and the XKMS design effort. I was told to
get this done immediately as it affects the last call that I understand is
currently on the table.
 
Background:
 Project DPLOY (  <http://www.projectdploy.com> www.projectdploy.com) was
initiated by IPsec product developers in an effort to work better with  the
PKI vendors to create interoperable tools needed for large scale,
PKI-enabled IPsec VPN deployments. Impediments to such large deployments
today include their complexity and operational difficulty, as well as a lack
of interoperable methods, multiple competing protocols, and some missing
components. To this end IPsec product developers have documented
requirements for IPsec product interactions with PKI products for such large
scale deployments. The requirements will be used to identify the protocols
and profiles (or create new ones as needed) that enable the IPsec and PKI
vendors to create interoperable, scalable deployment and management tools
for PKI-enabled VPNs. 
 
The desired outcome is that interoperable products would be created by both
IPsec and PKI vendors to enable such deployments, and created as quickly as
possible. 
DPLOY has a real requirements case to be considered in XKMS. It would be
nice to have a common framework and interface for PKI management for
different cert applications.


The current DPLOY draft calls for the use of CMC, but this was merely a
stake-in-the-ground position to begin discussions about a management
protocol. Don't let it scare you off. 
 
As we (the IPsec vendors) were drafting our requirements, I was keeping key
contacts at various PKI vendors updated and asking for input. After we
released the 1st complete draft of requirements we had a review meeting
where several PKI vendors were present. From those vendors I heard almost
unanimous encouragement to investigate XKMS as a contender for the single
certificate management mechanism. The reason was so that we would not end up
modifying current or inventing new protocols but rather focus on influencing
the areas of PKI which are currently undergoing development, i.e. XKMS.
 
Thomas Hardjono of VeriSign submitted a review of how XKMS could/could not
meet the DPLOY requirements (in the DPLOY mail archives:
http://postal.icsalabs.com/pipermail/projectdploy/2002-March/000036.html
<http://postal.icsalabs.com/pipermail/projectdploy/2002-March/000036.html>
). From this we learned that the current XKMS specs lack much of what DPLOY
needs, but were urged to press into the XKMS effort to voice the compelling
needs and get them included.
 
I am posting the DPLOY document as is so that you all can mull over the
delta between the current XKMS requirements document and the elements
defined by the IPsec/PKI community in DPLOY. I can see a couple of different
outcomes, either:
 (1) we incorporate most of the requirements from the DPLOY draft into the
main XKMS requirements document, or
 (2) we split the DPLOY elements out between various XKMS parts (XKMS main,
XBULK, etc.)
 
I look forward to the ensuing discussion,
Gregory.
 
 
**=====**=====**=====**=====**
Gregory M. Lebovitz
Staff Architect - CTO Office
NetScreen Technologies, Inc.
  e:  gregory@netscreen.com <mailto:gregory@netscreen.com> 
 ph: 408.730.6002
text page (<80 Chars):   page.gregory@netscreen.com
<mailto:page.gregory@netscreen.com> 
fax: 408.730.6200
web:  <http://www.netscreen.com/> www.netscreen.com
NASDAQ:   NSCN
**=====**=====**=====**=====**