Profiling Use of PKI in IPSEC (pki4ipsec)

 

Monday, March 7 at 1530-1730

============================

Chair(s):

Paul Knight <paul.knight@nortelnetworks.com>

Gregory Lebovitz <gregory-ietf@earthlink.net>

 

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.

 

Summary

 

The pki4ipsec WG addressed two current drafts:

 

(1) "Requirements for an IPsec Certificate Management Profile,"

draft-ietf-pki4ipsec-mgmt-profile-rqts-02.txt

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.

 

Key decisions:

- 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,"

draft-ietf-pki4ipsec-ikecert-profile-04.txt

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.

 

Other decisions:

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 ***************

 

Detailed minutes

 

     -----------

 

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"

 

                ...

 

 [next]

 

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."

 

Issue: 'Organization'

 

 '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"

 

'Pretty Picture'

'Basic Enrollment Process'

'Admin Authorization Process'

'Template Creation'

'Request Authorizations'

'Get Authorizations Back'

'Authorization Cancel'

'EE Request Structure'

'EE Response Structure'

'Error Responses'

'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?

 

'CMC Requirements'

'Unmet Criteria'

'Open Issues'

 '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?"

Jim: "Yes"

 

'Questions'

 

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?"

 Jim: "Yes"

Sam: "Ow"

 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"

               

mumble

Sam groaned.

 

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?"

Jim: "Yes"

 

 Chair: "Let's say nothing changes in the template, can you still renew."

 mumble

 

 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.

 

Milestones

 

 AOB