Last Modified: 2005-01-24
|Done||Post Certificate Profile and Use in IKE as an Internet Draft|
|Done||Post Management Protocol Profile Requirements as I-D|
|Done||Rev Requirements for management protocol profile as needed|
|Jan 05||Submit Certificate Profile and Use in IKE as WG last call|
|Feb 05||Submit Requirements for Management Protocol Profile as WG last call|
|Mar 05||Submit Certificate Profile and Use to IESG, Proposed Standard|
|Mar 05||WG decision on other Enrolment/Management protocols to profile|
|Mar 05||Submit Requirements for Management protocol Profile to IESG, Informational|
|Apr 05||Post CMC for IPsec VPN Profile as Internet Draft|
|May 05||Post other enrolment/management profiles as I-D|
|Jul 05||Rev CMC for IPsec VPN profile as needed|
|Jul 05||Rev other enrolment/management profiles as needed|
|Sep 05||CMC for IPsec VPN profile to WG last call|
|Oct 05||Other enrolment/management profiles to WG last call|
|Oct 05||Submit CMC for IPsec VPN Profile to IESG, Proposed Standard|
|Nov 05||Submit other Profiles for enrolment/management to IESG, Proposed Standard|
|Dec 05||Re-charter or close|
Profiling Use of PKI in IPSEC (pki4ipsec)
Monday, March 7 at 1530-1730
Paul Knight <email@example.com>
Gregory Lebovitz <firstname.lastname@example.org>
The minutes reported here consist of two parts: a summary, and details noted by Nico Williams. Many thanks (and $4.00) to Nico for his efforts.
The pki4ipsec WG addressed two current drafts:
(1) "Requirements for an IPsec Certificate Management Profile,"
Most of the WG meeting was focused on this draft.
This draft describes the requirements for a profile of a certificate management protocol to handle PKI enrolment (certificate request and retrieval) as well as certificate lifecycle interactions (certificate renewals/changes, revocation, validation, and repository lookups) between IPsec VPN systems and PKI systems.
- The authorization ID and token formats need to consider internationalization (i18n) requirements such as the use of UTF8, and explicitly describe the reasons why the format is chosen. stringprep may be appropriate for the passphrase (token)
- Enrollment TYPE field currently has change/renew/re-key values. A consensus call on this point resulted in a decision to drop the requirement for secondary request type -- no update/renew/rekey, just enrollment and renewal. This should allow removal of the TYPE field. The consensus was unanimous.
- There was also unanimous support for recognizing that there are still requirements for changing, renewing, and rekeying, but the TYPE field is not the way to address these requirements.
- There was no clear decision at the meeting on whether to remove from requirements the ability to have the PKI (not admin or peer) to generate key pairs. This will be decided on the mailing list.
ACTIONS: Document authors to issue a call for consensus on the mailing list to validate the decisions, and to decide on the undecided issue. Then update the document to reflect WG decisions, and make a WG last call.
(2) "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX,"
Due to a series of unfortunate events, this draft was not discussed in detail
- Author unable to attend IETF 62
- Although submitted in January, the updated draft never appeared in IETF repository.
ACTIONS: Chairs and author to ensure draft is available on IETF site. It is currently on the ICSA site, http://www.icsalabs.com/html/communities/pki4ipsec/draft-ietf-pki4ipsec-ikecert-profile-04.txt.
Jim Schaad will begin as author/editor of a profile or protocol document to address the requirements described in draft (1) above.
FUTURE: Move drafts (1) and (2) to WG last call ASAP, focus on new draft.
**************** End Summary ***************
Speaker (Sean Turner) describes interim meeting, talks through slides
Talked about confirmation handshake, no consensus -> need to go to list.
Internationalization (I18N) issues for "authorization token format" -- questions from floor: what is that?
Chair: "Whoever is working with the PKI admin is going to gen for a user or set of users an ID and a passphrase, which will be communicated to the End Entity (EE) somehow, OOB."
From the floor: "Anything that doesn't do I18N will get bounced by the APPS area." (Marcus Leech)
Back and forth, Sam Hartman and chair,
"what's this for, who gens it"
"it's an ID, it's genned by the admin"
"so it can be all-ASCII, but does it have to correspond the user's name"
"sort of, (yes)"
"so then you MUST do I18N, learn about stringprep or this will be blocked"
"so why aren't we internationalizing this, because it's hard?"
someone says "we can I18N the ID part, but don't want to I18N the passphrase"
all: :) "no, you can and should stringprep the passphrase"
Issue: 'Enrollment TYPE field'
How to figure out change/renew/re-key type?
Whether to specify type or let peer figure it out and do the right thing.
-> Take it to the list
Issue: 'Cancel/New Auth -- need new identifier for replay protection'
Issue: 'DNS support for PKC path lookup and revocation?'
Issue: 'Certificate Authority (CA) state info needed'
"The CA will have to maintain some state, it's pretty obvious; has to be added to the document."
'Key generation/PKC request options'
Chair and Speaker agree to fix up text/figures, let WG decide key gen issues.
Chair: People should review, contribute to the requirements document.
'CMC and PKI4IPSEC'
Speaker: Jim Schaad
Issue: 'What does a MAY really mean in a reqs doc?"
Issue: 'What does a SHOULD really mean in a reqs doc?"
Issue: 'Reqs on admin <-> peer connections'
Issue: 'Reqs on PKI structure and other structures in the system'
Chair: "Can you give an example"
Jim: "Like 'you have to have a repository' -- why's it there, how do you use it"
'Basic Enrollment Process'
'Admin Authorization Process'
'Get Authorizations Back'
'EE Request Structure'
'EE Response Structure'
'Update, Renewal & Rekey'
Renewal -> cert is same
Rekey -> cert content is same but pubkey is diff
Update -> cert content is diff, pubkey possibly included
'Renewal & Rekey'
Jim: What happens when a rekey turns into an update due to policy changes?
'Queue and Manually Approve'
Chair: "Don't want to mandate automatic process"
Jim: "Internals of CA are out of scope for this document"
Bill Sommerfeld: "But the reply may not be instantaneous, does the doc say this?"
Chair: "How do you define controls"
Jim: "By OIDs"
Chair: "So the issue 'what if the template changed...', can we discuss that? I think the options are: yes we need renew rekey, update, or no we don't."
Jim: "Well, the renew/rekey are easy, no need to change current behaviour... The question is: do you allow update, or is update a new enrollment."
Sam: "Wait does that mean that a new authz ID/token?"
Sam: "Reviewing manually is different from getting a new authz token"
Is the template tied to the DB?
Jim: "Probably not."
Nico Williams: "So, can new templates indicate whether old tokens must be updated, not renewed?"
Jim: "Yes. The DB can recall the template that had been used for a given cert."
Stefan Santesson: "Could use an extension"
Russ Housley: "Would a VPN as a rule only need a single template?"
Sam: "At a protocol level can you make it work if people are willing to store certain info?"
Chair: "Let's say nothing changes in the template, can you still renew."
Stefan: "Why does the client need to know which of update/renew/rekey to do?" "Why can't it be told?"
Chair: "The req that the EE be able to gen the keys forces us to have the EE involved in this"
Someone: "Who's the most likely party to recognize that there's a security problem?"
Jim: "What kind of attack are we looking at? It depends on the attack."
Chair: "Can we make a decision here?" "Does anyone object to the dismissal of the 'update' type?"
<lots of discussion, redundant discussion, not following>
Will go to list. The answer from Russ is: separate authentication and authorization.
Consensus call: "We are going to drop the requirement for secondary request type -- no update/renew/rekey, just enrollment and renewal." Unanimous YES.
Consensus call: "Then, do we keep the requirements for the functionality." Unanimous YES.
Back to PKI generation of keys.
Consensus call: "Remove from requirements the ability to have the PKI (not admin or peer) to generate key pairs."
Take it to the list.