Proposed PKI4IPSEC Certificate Management Requirements Document

1
Proposed PKI4IPSEC Certificate Management
Requirements Document

• IETF 59 PKI4IPSEC Working Group1 March 2004
  Seoul, Republic of Korea

Chris Bonatti (IECA, Inc.) ltBonattiC_at_ieca.comgt Tel
(1) 301-548-9569
2
Status of Draft

• Publication history
• draft-dploy-requirements-00 2002-MAR
• draft-bonatti-pki4ipsec-profile-reqts-00 2004-JAN
  -30
• Requirements are based upon the existing Project
  DPLOY work, but have been extensively tailored to
  the PKI4IPSEC charter and assumed scenario.
• Currently published as a personal draft pending
  acceptance into the WG.

3
Document Structure

• 1. Introduction
• 2. Architecture
• VPN System (VPN Peers VPN Admin)
• PKI System (CA, RA, Repository)
• VPN-PKI interaction (steps in certificate life
  cycle)
• 3. Requirements
• Subsections address different requirement areas
• 4. Security Considerations
• Annexes
• A. References
• B. Acknowledgements
• C. Editor's Address
• D. Summary of Requirements
• Plan to include a summary table similar to those
  in RFCs 1122, 1123, and 2975.
• E. Change History

4
Changes to Draft

• Rewrote and trimmed to fit proposed scope of
  deliverable (2) from IETF PKI4IPSEC charter, and
  remove references to Project Dploy objectives.
• Added definitions of Community Realm, CRL
  Distribution Points (CDP), and Authority Info
  Access (AIA)
• Restructured the "Architecture" section to bring
  the presentation of Figure 1 to the front to go
  along with the overview of the section, and to
  add a new step diagram showing the certificate
  life cycle to the "VPN-PKI Interaction"
  subsection.

5
Changes to Draft (2)

• Added a new subsection 2.1.2 to describe the VPN
  peer.
• Subsection 3.2 was deleted to maintain the focus
  on generic requirements agreed in Minneapolis.
  Selection of specific protocols will be done in
  the deliverable (3) profile.
• Deleted the requirement from 3.2.3.1 to include
  the maximum CRL size in the certificate template.
  This may need to be specified in the profile,
  but not be in the certificate itself.
• Revised 3.3.3 to to clarify that key escrow
  requirements and any key transport between the
  VPN admin and the peer are beyond scope.

6
Changes to Draft (3)

• Added AIA extension as a MAY requirement in
  3.5.2.
• Removed the requirement for HTTP support in favor
  of a requirement for a single mandatory protocol
  to be specified in the profile.
• Removed subsection on "Intra-IKE Considerations"
  as these should be dealt with in the existing
  deliverable (1) PKI profiles.
• Considerable editorial revision was also done.
• See Annex E for a complete list of changes.

7
Big Issues

• Expansion of scope to include case where VPN
  admin does not exist.
• Expands from 80 solution to 90, by picking up
  the lower tail.
• Requirements and solution need little change as
  scenario is the same as a community of one with
  the Peer and Admin collocated.
• Pre-authorization is obviously not necessary.
• Reconsider the adequacy of Figure 2 to elaborate
  the complexity of the certificate life cycle.
  Should it, perhaps, be split into multiple
  figures?

8
Big Issues (2)

• Section 3.3.4 needs to be generated pending WG
  approval of additional use case for PKI
  generation of keys.
• Need to determine the relationship between IKE
  certificates, and certificates for ongoing cert
  management use.
• Closure on MUST ID fields in IKE certificates
• Certificates MUST contain at least one of Subject
  or the SubjectAltName iPAddress, dNSName, or
  rfc822Name.
• Some question of whether or how Key_ID will be
  supported. Perhaps SubjectAltName otherName can
  support.

9
Big Issues (3)

• Section 4 (Security Considerations) needs to be
  generated.
• Annex D needs to be generated.

10
Way Forward

• Propose that this draft be adopted by the WG as a
  first cut at the Informational RFC described in
  charter deliverable (2).
• Continue to address issues and massage
  requirements.

11
Questions?