Profiling Use of PKI in IPSEC (pki4ipse) Notes

Scribe John McLaughlin, johnmcl@us.ibm.com

 

November 10, 2004

 

CHAIRS:

Paul Knight <paul.knight@nortelnetworks.com>

Gregory Lebovitz <gregory-ietf@earthlink.net>

 

 Jabber scribe: Bill Sommerfeld

 

1.  Notes Structure

Issues

Key Decisions

Next Steps

 

2.  Agenda and Milestones

 

Issues

(Paul Hoffman)  Paul raises points out that there’s little traction being made on his issues.  He thinks his issues could swamp the last call, so recommends not going to last call on management protocol profile.

 

Key Decisions

(Russell Housley)  Milestones approved

 

Next Steps

None

 

3.  Status of draft: "Requirements for an IPsec Certificate Management Profile"

 

Issues

(Barbara Fraser)  Barbara raises questions on the VPN admin role and the relationship of the admin role to work being done in other working groups.  She points out that the author appears not to have investigated that relationship.  That lack of investigation may cause conflict with other working group’s direction.

 

(Gregory Lebovitz)  Gregory points out that the VPN admin function does not have definition or content beyond the scope of the PKI interaction.  The admin function is not a loaded term implying anything more than the authority in the document.  The function is simply an administrative function brokering communication services between IPSEC peers and the PKI system.  In addition, the function is not necessarily a stand alone device and could be co-hosted on the same platform as other functionality.

 

(Paul Hoffman)  Paul sees the templates out of scope as the functions are out of scope.  Some basic components can be defined, but the external entity will define the rest of it.  He recommends not defining anything more than the base requirements.  He also notes  that the template will be human completed.  He thinks the content will be human defined so don’t add more requirements or components

 

(Gregory Lebovitz)  Gregory replies that the template format is defined so explicitly so that other CA vendors can interact.  Human interaction happens once for each individual registration so the specificity is probably not more than a one-time challenge.

 

(Paul Hoffman) Asks if the scope of the VPN admin function is all X.509 attributes?  Author suggests that PKI negotiation will define the attributes.  Suggests that content is in excess of X.509 attributes.  Authorization attributes are an example.

 

(Paul Hoffman)  CMC must change to be able to deliver desired qualities.  Paul has a concern that the level of change could be bigger than expected.  To protect against expanding change content, he wants to scope down the change capability.   To facilitate such, he suggests strong coordination with other working groups.

 

(Gregory Lebovitz)  Gregory recognizes the above issues and points out the need for quicker resolution.  To facilitate quicker resolution, Gregory proposes an interim gathering of the WG.  Gregory takes the action to drive the interim meeting.

 

Key Decisions

An interim meeting will be scheduled for further work on  "Requirements for an IPsec Certificate Management Profile"

 

Next Steps

(Lebovitz) Schedule the WG Interim Meeting. 

 

 

4.  Status of Draft and Review of Changes Between -01 and -03:    "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX" (Brian Korver),

 

Issues

 

(Gregory Lebovitz) Challenges CDP mandatory text can be removed. 

 

(Paul Hoffman)  Paul disagrees that the negotiated settlement holds non-important content.  If entities can not rely on the CDP, then they must alternatively agree to the revocation process in advance.  In short, CDP text is not needed.

 

Now onto issues 654 and 576.    The question is amount of content in certificates.  The question is reformed as to the degree of intermediate trust chain content.  The alternatives are to send everything in band or send only the minimal set of attributes.

 

(Michael Richardson)   Michael points out that at the PMT meeting yesterday this idea was discussed.  The general consensus was to use IPsec and except for UDP issue, let people put as much content in as they wish.  Gregory Lebovitz asked how the UDP fragmentation issue was solved while including in-band intermediate certificates.  Without changes to IKE, Michael says no.  Michael’s position is forbid what people are going to do in normal course of business.  He also points out there should be some method for long chains.  Alternatives include IKE level fragmentation process or simply sending more packets.  Michael said his experience shows that VPN has broken on several systems and hosed up the UDP level.

 

(Bill Sommerfeld)   Bill points out that the answer  may be to come up with a viable out of band (OOB) mechanism.  Don’t bar in-band techniques through preclusionary specification until a viable out of band capability exists.  Gregory Lebovitz points out that the current RFCs do specify what an out of band mechanism is.  Gregory states there are out of band mechanisms available, just not specified.

 

(Steve Kent)  It is reasonable to expect that certificates can be gotten by a single individual.  Don’t use CMP/CMC as examples.  He also points out that UDP fragmentation is still the big issue.  Steve also agrees with Bill and Michael that a concrete description for an alternative should be in place prior to directing not to use in band processes.  He then speaks to infrastructure complexity. He draws an analogy showing the conflict within the security group being both paranoid and ready to relax complexity.  The example in front of us is that we favor of sending revocation in band and look for out of band solution. 

 

(Charlie Kaufman)  Charlie prefers solutions that are backwards compatible.  PKI accessibility is a challenge for any out of band transmission technique.  Storage is a challenge too.

 

(Paul Hoffman)  Paul agrees with Steve.  He thinks the problem is larger than UDP fragmentation.  He points out that each certificate has revocation information.  That revocation information needs to be transmitted too.  One can either can send the intermediate certificates and all revocation information or one doesn’t need to send intermediate certificates.  He also agrees that an out of band solution is better and consequently we wait for an out of band solution.

 

(Wes Hardaker)  Wes thinks we are not determining the target audience.  The challenge is that a lot of information needs to be sent in a protocol that doesn’t support it.  One option is to solve the simple problem first.  The larger problem is that the infrastructure does not support the solution.   Proposes that an 80% solution could be more desirable than a more complete solution delivered far into the future..

 

Wes also recommends that trust anchors are not to be sent in band.  Concerns are that infrastructure can’t support all functionality.  Suggests that the number of people using intermediate certs is pretty small.   Does not see need for in band revocation information to be sent.  Recommends finishing the profile and publishing.  Then fix the problem for he small number of people using it.

 

(Stefan Santesson)  Stefan sees another problem in that revocation information may need additional certificates, which might need revocation information of its own.

 

(Bill Sommerfeld)  Bill accepts the idea of an OOB roadmap, even if it's not here yet.

 

(Russell Housley)  Russ has an alternate position.  He sees it desirable to nail down what we can nail down now.  He recommends leaving out OOB and move forward on the rest of the stuff.

 

(Michael Richardson)   Michael speaks that cert chains are difficult to test and inject uncertainty.  The point is that the payload can be either well defined or just pushed off to another function.

 

(Charley Kaufman)  Observation on unsolvability of problem.   Decision is between an implementable standard now and those that look for viability of an alternative decision.

 

(Steve Kent)  Alternative is put a reference in text that we are not addressing intermediate and OOB or not.  We are addressing format of the profile.  Publish that OOB decision and implementation is coming later.  Leaves acquisition method undefined. 

 

(Hank Mauldin)  Reminds the group that the charter says don’t break any functionality and he’s concerned that a poorly implemented OOB decision will break functionality.

 

(Paul Hoffman)   Puts forward the question on whether OOB would be used if a viable mechanism was available.   He recommends moving forward on list discussion on the question.

 

(Michael Richardson)  Michael sees existing deployments as a red herring.  He points out that implementations will be 4001 compliant or not.  The real question is what would we do if this was a blank slate?

 

(Wes Hardaker)  Wes points out that network operators should be polled.  Gregory points out that network customers just want it to work.

 

Key Decisions

 

Forbid CRL in band.  Refer to coming work for OOB acquisition.  Pass by consensus

Allow CRL in band.  Failed by consensus

 

Forbid intermediate certs in band.  Failed

Allow intermediate certs in band.  Passed by majority

 

Do we prefer IB ideally?  Some small number of hummers

Do we prefer OOB ideally?  Some incrementally larger number of hummers.

 

Proceed with draft and address intermediate certs.  Strong majority

Proceed with draft and remain silent on intermediate certs.   Minority present

 

Next Steps 

Captured in brief by Brian

Resolve issues

Submit 04 draft

WG last call

 

5. "Refining the IPsec Peer Authorization DB" - presentation by Steve Kent

 

Issues

 

(Michael Richardson)   Michael indicates that the NOT condition on SA constraints is not sufficient.  Proposes that logic condition is a lot more complicated than presented.  Recommends that Buttons WG work out the details.

 

(Bill Sommerfeld)   Questions Steve Kent on his intent that the brief be turned into a draft.  Steve Kent replies yes if it can be done quickly. If not, then its separate draft to be considered at the next IETF meeting.

 

Key Decisions

 

Draft evolution is to done on the list by consensus (hum).

 

Next Steps

 

Participation level to increase.  Deadlines have been missed.  One of those move-out kind of things.