2.6.14 Profiling Use of PKI in IPSEC (pki4ipse) Bof

Current Meeting Report

1st BOF, IETF58 
(Minneapolis, MN)
Thur 2003.11.13, 0900-1130

Gregory Lebovitz
Steve Hanna 

Minutes compiled by Gregory 
Lebovitz, from notes by:

  Tim Polk, Brian Korver, Chris 

POC Information
List:	pki4ipsec@

Info:		http://www.ic
Subscribe:	http://

Archive:	http://hono


We're here to answer the 
question:  How do we use 
certificates within IPSec?  What 
goes in them, how do you get 
them, how do you exchange them, 

Goals: to guage interest, refine 
the charter and decide whether or 
not to start a WG on this topic.  

Rules of engagement:  A 
non-goal is to get into the 
worktoday. Want to focus on 
clarifying questions and then save 
enough time for charter 

Will go over work that has 
already been done, but only to see 
if that work is relevant to the 
work of the group.  Not to go into 
the details of that work. Please 
limit questions to 
clarifying questions. Hold 
comment until the Charte 

PRESO: Needs Assessment from 
OASIS PKI TC, Steve Hanna:

<see Steve's slides>
- OASIS PKI TC is customers, 
vendors, experts and is devoted to 
identifying obstacles to PKI 
- items holding back 
deployment: PKI support in 
applications and cost were top 
- This BOF addresses 3 of the 5 top 
obstacles identified by their 
Their Action Plan identifies a 
need for this sort of group
- The proposed charter being 
considered by this BOF is 
narrow. That's fine, but please do 
not do anything that 
precludes use of PKI for other 
applications as well!

PRESO: PKI for IPsec 
Architecture, Gregory:

<see Gregory's slides>

presented the architecture for 
PKI-VPN administration from the old 
dPloy document

three VPN components - an admin 
function and two peers
three PKI components - CA, RA, 
six different types of action: 
authorization; generation; 
enrollment; IKE/IPsec; 
maintenance; renewal

Barbara Fraser:  What parts of the 
architecture slide are 
in-scope and out-of-scope of the 
working group?  

Gregory: What we're basically 
proposing (sneak preview):  what 
you fill in a certificate, 
usage, that's in scope.  We also 
want to talk about 
interaction wrt request and 
retrieval, and 
lifecycle maintenance.

Steve Hanna:  2 things: the PKI 
profile document and then 
lifecycle management (CMC).

Bill Sommerfield:  IPSec isn't 
just for VPNs. wants to note that 
VPN should not be the scope, 
IPsec should be the scope

Gregory:  It's 
intentional.  We 
acknowledge that IPsec has other 
uses, but the charter is 
VPN-specific.  The reason is that 
Russ (AD) wants to charter 
tightly, to get done the most 
important immediate need and then 
fill in the edge cases after a 
possible re-charter.

Bill:  That makes this effort less 
interesting to me. Thinks the 
scope is too narrow.

Paul Hoffman:  What Gregory has put 
up here is the 
architectual framework of the 2nd 
part of the charter.  The 1st 
part, the certificate formats and 
what is allowed in the IKE 
messages, and the 
interaction in IPsec is 
applicable to all IPsec.  
Although the working group will not 
all be on VPNs.

Wes Hardegar?:  Is there a 
technical reason that caused the 
narrowing the focus, or was it a 
decision that we just didn't want to 
deal with it.  I'd rather assume it 
includes everything until we come 
across something that causes us to 
drop the requirement to support all 

Gregory: non-technical. More of a 
scoping thing. 

General agreement that we could 
continue along the path with 
host-to-host until such a time as 
the host-to-host was slowing 
things down, or seen as a big 
impediment, then drop it.

Max ???:  Can you clarify the PKI 
admin function?  Is this admin for 
VPN and PKI, or just 
PKI-specific? What about key 

Gregory:  Admin is something that 
for this WG we might just want to 
toss.  It's part of the VPN 
system.  This is where the 
policy comes from.  It could 
exist on some management 
system, or it could reside in the 
vpn boxes. It could be a 
separate daemon or an 
integrated fucntion. It is a 
functional component, not a 
network element. Whether or not it 
resides on the element depends on 
the vendor (and they are all over 
the board).
Key generation occurs either in the 
Admin Function or in the IPsec 
Peer element. I could also, 
possibly, exist in the PKI 
system and be passed down to the 
VPN Admin function or directly to 
the IPsec Peer element.

David Berkins - doesn t 
understand why the 
authorization function is  
muddled up  with certificate 
Gregory - authorization label on 
that part of the diagram in this 
architecture is 
authorization to be issued a 
certificate by the PKI system. It is 
a request from the VPN-Admin 
Function to the PKI system 
saying, I want this 
device/person to be issued a 
certificate with they so 
request. NOT 
authorization for access to a 
particular system or file, nor to a 
match to IPsec SPD. 

Max ???: I'm unclear about [G] (on 
the architecture ASCII 

Gregory:  [G] is out of scope 
here. It's how the VPN Admin 
function, if off-vpn-box [not 
located on the network element 
itself], communicates to the VPN 
Peer. It is labeled and called out 
so that we can be clear about it, 
and clearly say it is out of 

-pki-profile-03.txt, Brian 

<see Brian's slides>

one of the editors of IPsec PKI 
Profile; currently in IPsec group
provides a profile of ISAKMP and 
PKIX for use in IPsec
complements IKE v1 
still a strawman, hasn t 
received sufficient attention to 
Scope includes:
when should you send certs and or 
what if CERTREQ is empty

Current draft is -03; has not 
changed substantially since -02
what is needed for -04:
scope to match this WG
incorporation of feedback

Barbara Fraser:  
In IPsec WG, we were busy. his 
document was considered 
separable from the core 
documents and did not pursue it (1) 
in hopes of finishing the core 
IPsec documents and (2) in 
anticipation of formation of a new 
group that would handle this 
work. glad to see this 
document move forward.

Gregory: how much comment 
received to date?

Brian: only about five people have 
submitted comments

Eric Rescalora (other editor): 
note that issues in IKEv2 should be 
able to be easily addressed in 
this specification; Eric 
believes IKEv2 should be in scope 
for this document

PRESO: PKI Profile for IPsec, Paul 
(co-author of long dead PKI 
Profile document)

<see Paul's slides>

His spec differs from Brian and 
Erics; Paul has different view. 
[doesn't have a spec, but 
intends to write one or 
co-author with Brian and Eric. 
just presented the main outline of 
the doc he will write, and 
highlighted contention points with 
Korver draft.]

Scope of old 
specification was:
·	assumptions
·	identities
·	key usage
·	cert expiration
·	req d algorithms
·	CERT and CERTREQ payloads
·	path validation
·	cert revocation
·	enrollment for devices
·	purpose is to identify a 
·	both parties need to trust the 
CA(s) fully
·	most often, parties control 
their own CA
·	PKIX is full of features that are 
not needed in IPsec
Identities (in 
certificates, not in 
·	match access rights
·	no need to match the IP 
·	PKIX naming is a mess
·	cert should have NULL subject 
one discriminator between the 
proposals is whether or not the IP 
address of the identified entity is 
bound into the 

Not sure whether we should just 
come to agreement or whether he 
should rev his spec.

Lauri T.: I'd be surprised if an 
organization would delegate 
authorization to their CA. CA does 
not establish access 

Paul:  Agreed.  That's the role of 
the organization.

Eric Rescorla:  the point of IKE is 
to create table entries for SAs and 
allowed IP addresses. That can 
either be done by treating cert 
identities as opaque lookup keys 
for a policy table or as the 
addresses that should appear 
directly in the IPsec access 
control table. I think both are 
valuable. The goal of our draft 
here is to make the first kind of 
identity not look like the 
second. two ways of using this; may 
in fact want to match IP 
address and reject if they don t 
match.  This is a place where the 
two documents diverge and EKR 
believes that both models needed to 
be supported.

Steve Hanna noted that we have 
started the work of the WG, but we 
are a BOF.  Let s hear our 
possibilities and move on to the 
charter discussion.

Path validation is hell but may be 

Summary of Hoffman slides:
·	Need to make it useable 
without reducing actual 
·	Must be willing to break some 
·	Acknowledge previous efforts 
inadequate and fix it.

PRESO: Requirements for 
PKI-for-IPsec Profile, from 
Project Dploy work, Gregory:

<see Gregory's slides>

published a requirements 
had about ten drafts although only 
the last was ever publicly 
Cert management 
requirements (CMC was selected 
after a lenghty analysis and 
debate between CMC vs CMP. We do 
not want to re-live that here).
Cert profile
finding certs and CRLs
intra-IKE considerations

Effort stalled after 
requirements document because PKI 
vendors were not really 

Still, felt the project was valid 
and that the output should be 
considered as input to this 
project, i.e. take the 
contents and lessons learned and 
build them into a 
requirements draft or fit where 
applicable in profile draft.

Latest version of charter was 
emailed to list this morning. 
Gregory gave overview of 
charter, with it on overhead.

Eric Fleishman (Boeing):  This 
work would be much more 
valuable if it included 
transport mode as well as tunnel 

 Not interested in tunnel mode at 
the moment but transport mode 
would be a valuable addition for 
other protocols such as SNMP
I also object to putting IP 
addresses into 
certificates. IPaddress is not a 
fit basis for identity.  For 
example, mobile networks etc do not 
fit that model at all!

Suggest scope of the working 
group should be expanded to all of 
IPsec, specifically to include 
remote access vpn and site to site 

Gregory:  I don't see why 
transport mode isn't a part of 
enterprise-scale IPsec 
deployments. By VPN we don't mean 
tunnel mode, we are using a more 
loose definition of VPN than 

Steve - please hold these 
comments until Gregory 
presents the draft charter

WG Deliverables:
(1) standards track document that 
gives specific instruction on how 
X.509 cert s should be 
formatted and populated, and 
handled in IKEv1 and IKEv2.
(2) informational document 
describing and identifying 
requirements for a profile of CMC 
for these systems.
(3) a standards track document CMC 

Skew:  favor use cases for large 
single domain deployments (e.g., 
exclude very small or gov t - to 
gov t, or 
multi-inter-domain use cases)  
site to site VPN or end user 
remote access VPN 

Non -goals: exclude purely PKI 

Agreement that we should focus, but 
take the low hanging fruit when 
possible, but not let such slow us 

Milestones are aggressive.

Bill Sommerfeld:  Asked Paul 
Hoffman: why he said #2 was more 
applicable to tunnel mode, when he 
thinks that it is more 
applicable to transport mode.

Paul: doc 2 is about 
lifecycle&  diff scenarios

Bill:  You see the problem as 
getting certs to gateways is a 
different problem from getting 
them to users.  But in large 
VPNs, the problem may be the 

Gregory:  We're here to 
determine if there's enough 
interest in forming a working 
group.  Asked Bill: what 
textual change would you make to 
the charter?

Bill:  The difference isn't 
tunnel vs. transport, it's 
between centrally managed 
deployments vs. end-user certs, and 
that's the way to slice it.

[some attempt was made at 
creating appropriate text]

Gregory:  We don't have to 
finish the charter here. I think we 
get the spirit of the 
intention. We can wordsmith 

Bill:  "Gateway" implies VPN to me.

?:  I didn't understand if the 
last comment changed the scope, or 
added to the scope.

I think enterprise 
deployments are going to want to 
change.  End-point to 
end-point IPsec is going to be 
needed because of Wireless.  Need to 
take that into account.  More 
useful to consider the 
problems of the future (the full 
problem) rather than 
concentrating on just the scope of 
the problem today. 

Gregory:  do you think waiting a 
year to tackle that future 
problem is waiting too long?

?:  No, that would be okay. But 
don't want to disregard it now, 
such that we exclude it later.

Hoffman clarified that using 
IPsec in tunnel mode between two 
gateways has some very 
different PKI 
considerations than using IPsec to 
secure applications.

Gregory:  Proposal:  add text to 
charter: let's consider the full 
problem until it bogs us down. 

Steve Hanna: stated that he did not 
see this as a problem.  The slope 
that housley was concerned with 
avoiding was the work of 
ENROLL, and this doesn t 
approach that.

Tim Polk:  I've got some 
concerns about the scope.  This 
charter is an improvement to the 
original.  I believe doc #1 is the 
most important one, and if it was 
the only document this group did it 
would be sufficient.  That's the 
document that really matters. Re: 
doc #2, there's no reason that #2 
has to be about CMC.  Doc #3 is 
where CMC would be mandated (if 
that's the management protocol 
that group chooses).  
Certificate management 
protocols are a snake pit and I 
don't want to see #2 and #3 
prevent progress on #1.  I'd like to 
see the milestones 
restructured so that #1 gets done no 
matter what.

Gregory:  Agreed.  I think the 
snake pit experience we had with 
dploy was the disagreement on 
which cert mgt protocol to use, 
rather than cert mgt 
protocols in general.  That's why we 
choose to go with CMC.

Tim Polk:  You should be able to 
change the acronym "CMC" in the 
charter and it shouldn't change the 
contents of doc #1 at all. If 
that's not true, then PKIX 
screwed up.

Lauri T.:  I'd like to remind 
everyone of the aggressive 
schedule. If we're going to meet 
that schedule, we do need to keep 
the scope limited.  

Tero Kivinen: I'd like to 
recharter this now to include doc #1 
and drop doc #2 and #3.  I also 
don't like that the schedule has 
the group doing all 3 
documents at the same time.

Paul Hoffman:  Perhaps we could 
split the difference and drop #3, 
since nothing in #2 should have any 
effect on #1.  Also, if we are 
explicit about CMC, 
proponents for other mgt 
protocols will stick stuff into #2 
that only their protocol 
supports. That's a problem that we 
experienced in dploy.  #2 needs to 
be completely generic.  Asked 
Brian, have you seen anything in 
your work where #1 would depend on 
anything on #3. 

Brian:  No. 

Paul: Would be happy to hold #3 as a 
re-charter item; believes that WG is 
necessary to keep them honest at 
this point.

Gregory: acknowledged that this was 
probably useful, but stated that he 
did not want to see the work on (2) 
or (3) deferred for a year.

Bill Sommerfeld: believes that 
Document 2 may have minor 
dependencies for Document 1. 

Russ Weiser:  I support doing #1 
and #2, and holding off on #3.

Gregory:  The first thing 
someone needs to do is to get 
certificates on their box.  So if we 
only do #1 and #2, then we've 
moved them no closer to 
deployment.  It may be that we 
have to do #1 and #2 first 
before we can do #3.

Brian:  I'd like to vote for 
dropping #3 from the charter. 
There are enough 
contentious issues in #1 and #2 
that doing #3 is parallel is a bad 
idea.  I also like to vote for 
dropping CMC from #2.

Tero: doesn t agree that is the 
first problem. believes 
interoperability is the first 
problem.  Even once the keys are in 
the boxes it is hard.

Paul: really need to do 2 first.  
writing requirements and 
implementation spec in 
parallel is a mistake.  

EKR: recommend 
re-chartering later to handle 3.

Gregory:  I think we're almost 
done with #2 using the dploy 

Tim Polk:  I think that if we do a 
good job on #2, then #3 will be 
easy. Think it can still be done in a 
reasonable time frame.

?:  There seems to be an 
assumption that producing these 
documents will be easy.  But 
there are others in the group and 
see this as a chance to do some 
interesting work. The question is 
how much of the work of this 
group is a continuation of the 
existing work, or wether it's a 
fresh start.

Gregory:  I don't think it's a 
continuation, the scope of dploy 
was much larger, but I don't 
think we should throw it away 
either.  We should start with it as a 

A hum showed that consensus was 
clearly achieved on mandating work 
on #3 not start until #1 and #2 are 
done, consensus on leaving #3 in.

Brian Weiss:  first two 
documents there is a lot of 
consensus that they are 
important and should be in 
there.  I'd really like to see the 
requirements first before we 
decide on CMC.

Steve Hanna: CMC is by fiat.

Paul:  I don't see why there 
can't be something beyond #3, 
other profiles.  I believe we need 
to have a #3 there.  I'm happy to 
have #3 be CMC. CMC is a 
reasonable choice; but should not 
exclude doing CMP or SCEP if 
someone and have the WG handle it. 
Mandating that #3 specify 
enrollment would exclude 
participants that had 
preexisting enrollments.  He 
would like to see (2) consider 
enrollment, but not have (3) 
mandate a specific 
enrollment mechanism.

adkins: stated that 
enrollment is too important to 
omit from (3).  He stated that we 
should describe a single way of 
performing enrollment, but not 
mandate that it is the only way of 
doing it.

Bill Weiss:  I hope that 
leaving #3 in doesn't stop us from 
moving forward on chartering the 

A hum showed that consensus was to 
remove "CMC" from #2.

?:  asked whether the timeline 
should be tightened up to 
reflect the expressed urgency of 
this work. I'd like to see the 
milestones for #1 and #2 be done 
ASAP, and then #3 started within a 

Steve Hanna: indicated that he 
thought the milestones were 
already fairly aggressive.  He did 
not see how we could compress the 
timetable for (1) and (2) 

?: What does "done" mean, then? 
What do we have to do before we can 
begin work on #3?

Gregory:  I think "done" means 
through WG last call. Agreed? vs 
IESG last call or RFC.


Lauri: milestones need to be 

Paul Hoffman:  I don't believe 
that enrollment is part of 
lifecycle management.

Derek believes that 
enrollment should be covered in a 
sufficient, but not 
necessary, e.g., a protocol that is 
not mandatory to implement

Steve Hanna:  Decisions of the 

First change agreed on was 
whether we could add support for 
transport mode.  Is it the sense of 
the BOF that we'd like to try to 
include support for transport mode 
to the charter, until such a time as 
it would bog down the effort, at 
which point it could be 
removed?  Agreement on that.

Another change agreed on was that 
we'll do #1 and #2 first, and only 
then will proceed with #3.

Also agreed that 
requirements will be generic, 
rather than specifically 
mention "CMC". CMC would be 
removed from #2.

Also agreed that Charter will 
explicitly list what we mean by 
certificate lifecycle, what 
covered by any protocol that 
might be profiled for #3 (eg 
retrieval, etc.)

Agreed (by hum) to add text that 
explicitly states that #1 is the 
most important.

Agreed to the charter with the 
changes above.

Agreed to move forward w/ 
charter and create WG.

25-ish people raised their hand to 
indicate that they were 
planning to *actively* 
participate in the WG.

Lots of people want to edit or 
draft text for #1.

No volunteers stepped forward to 
edit #2 during the BOF, but 5 or so 
came up to volunteer after.

Steve:  Looks like we've got 
enough interest to move forward on 
this, agreement on the 
charter, etc.

Gregory: special thanks to Steve 
for pinch hitting in Chair role at 
the last moment. GREAT JOB, huge 
value add to the process. 
[strong applause of 

Next Steps
	Agreed to the amended 
charter, post, along with 
minutes, and then get final 
agreement on list. 


pki4ipsec BOF Architecture Overview
Obstacles to PKI Deployment and Usage - Conclusions Relevant to pki4ipsec
The Internet IP Security PKI Profile of ISAKMP and PKIX
PKI profile for IPsec VPNs
Overview: draft-dploy-requirements-00