Subject: March 2003 IETF WG Minutes

From: Barbara Fraser <[email-masked]>
Date: Tue, 08 Apr 2003 18:18:41 -0700

Here are the minutes from the working group meeting last month. Please send 
any corrections to me by April 11 so that we can submit them by the April 
14 due date. Special thanks to Jesse for taking such detailed notes during 
the meeting.

Barb
=====================================
IPsec Working Group Minutes
March 2003 IETF, San Francisco, CA
Recorded by: Jesse Walker

1. Agenda bashing

Agenda accepted without change.

2. A word from the ADs

Russ Housley: Let's get it done. Oscillating on mail list. If it is in
document, don't change  it unless it is breaking something.

3. Draft status

Barbara Fraser:

modp group completed last call, RFC editor queue

aes xcbc-mac completed last call, waiting for IESG
aes-cbc completed last call, waiting for AD writeup
sctp completed, kicked back from IESG, but they had wrong version; being
rereviewed
ESP, 2402bis esn ready for last call

nat traversal ready for last call
MIB documents ready for last call, but can't find them

Dead Peer Detection document ready for last call

IKEv2 coming to closure?
IKEv2 tutorial

4. Update on ESP, AH, 2401

Steve Kent:

ESP & AH changes: revised identification text to better accommodate
multicast; clarified  anti-replay requirements for multicast; moved
discussion of when to use tunnel and transport  mode to 2401bis

Q: Remove mandatory algorithm references from AH & ESP? No response.

SA identification: unicast, SPI is sufficient. Multicast: should support
demuxing based on SPI  & dest addr, optionally use source addr too. Now SAD
flags to cover unicast and multicast: SPI  only, SPI + destination addr, SPI
+ dest addr + src addr

Q: What about protocol field in multicast case?

Anti-replay: transmitter always increments; receiver can ignore it. Receiver
should tell  transmitter to ignore seq counter wrap-around if not going to
perform anti-replay check.

2401bis: reconciling with IKEv2 selector, relaxing specs on when to use
tunnel v. transport;  add forwarding/routing lookup prior to SPD lookup.

Q: remove mandatory algorithm references?

Comment: Forwarding lookup also must return next hop address.

Q: Ready for last call?

Comment: If aligning 2401bis with IKEv2, does this mean it won't work with
IKEv1? Answer:  There are new SPD entries can't negotiate with IKEv1.
Comment: That is a real issue. Since  adding lots of valuable things, it
might behoove us to find a way to construct an IKEv1  profile. Answer: it's
ESP/AH that are ready to move forward, not 2401bis.

5. High Level Interop

There was a miscommunication between the working group chairs. This topic 
should not have been on the agenda.

6. Backend Config Payload  handling

Greg Lebovitz/Darren Dukes (Darren presents):

Use backend server to assign IP address.

IRAC Config Problem -- IPsec remote access client needs private IP address
before creating  child SAs. How?

Config Payload -- allow config payload to do this. Put config payload in
IKE-AUTH exchange  messages 3 and 4. Can backend with your favorite server.

On-IRAS Pools -- not scalable but work for small deployment

Off-IRAS Pools -- offload onto backend server; scales better: use DHCP,
RADIUS or other  backend server

Requirements: be able to use DHCP, RADIUS and LDAP to get addresses.

Question: Not suggesting changes to IKEv2? Answer: No, augments IKEv2 using
IKEv2 mechanisms.

7. IKE DHCP encapsulation

Michael Richardson:

Requirements: no new namespaces, provide client with info it needs; minimize
# of exchanges;  interfaces to existing infrastructure; preserves end-to-end
security of DHCP; permit independent  DHCP evolution.

Three methods: DHCP-over-IPsec; ModeCFG over IKE; proposed DHCP over IKE

DHCP-over IPsec: product of IPSRA; easy for bump-in-stack, all-in-one
gateway; leverages  existing DHCP server

ModeCFG: occurs in IKE msg 3, uses custom payload; if you need DHCP info, do
it over IPsec;  easy to interface to RADIUS/COPS/DHCP

Why bother? DHCP the defacto standard; don't reinvent

DHCP-over-IKE v. over IPsec: creating 0/0 tunnel is hard when crypto
offloaded; client systems  without virtual i/fs cannot do this easily; may
have to leave 0/0 SA around for renewals

DHCP-over-IKE v. ModeCFG: same as DHCP-over-IKE, except format bits; ModeCFG
needs an IKE 1.5  exchange; DHCP-over-IKE preserves client-server security;
extensible; plugs into RADIUS/COPS  with mini-DHCP server/proxy; talks to
real DHCP server with no glue

8. IKEv2 issues

Ted Ts'o:

Posted open issues last call to determine how far away from getting IKEv2
out the door.

Time to shoot the engineers and ship the product: if not broken, don't fix;
some recently  introduced problems should be remanded to an IKEv2 extensions
WG; otherwise will suffer scope  creep

What's left: AH and ESPbis; 2401bis; then we can shut down! Want to finish
this year.

Issues recently resolved: Secure legacy authentication; cipher suites
document needed--Jeff  Schiller has volunteered; Hugo's key derivation
objections; suites v. a la carte; Charlie's  question about IKE suite #5.

Issues recently discussed (no closure): Multiple tunnels for QoS; multiple
tunnels for  outsourced VPNs; mobility peer address management; kill
me-Tarzan-you-Jane; revised identity;  DHCP v. config payload.

Outsourced VPNs: is this important to handle now? Solutions exist that
require no changes to  the draft

Mobility peer addr mgmt: support for changing IP addresses during SA
lifetime. Important now?  assertion: move this into separate WG.

Comment: Defect in current draft about IP address. Can move this to another
WG. Charlie: if  clarifications to existing text, please send suggested text
and section changes apply to.

Comment: Combine NAT traversal, mobility? Ted: Don't see how the two are
related.

Comment (Mark Duffy): Include VPN ID in IKEv2. Within PPP have ways to
discover identities of  VPN members. VPN ID will facilitate this within
IPsec.

Comment: Suites v. a la carte: no idea what to do to support legacy
combinations that aren't  in a defined suite. Can't use IKEv2 with these.
Want to auto-upgrade configuration, but can't.  Response: It will have to be
allowed to use both suites and a la carte. We will leave IKEv1  customers as
IKEv1 until they can upgrade.

Comment (Dan Harkins): Will have to double suites because no way to indicate
PFS. Ted: Don't  understand.

Comment: If we go with suites, consider what other WGs have called out as
mandatory to  implement.

Comment (Charlie Kaufman): You can identify suite you want with vendor ID if
single vendor; if  multiple vendors want this, then they can ask for this to
be added to suites document.  Diffie-Hellman group is part of the suite.

Comment: Let's propose suite for every combination possible in IKEv1.

Comment (Paul Hoffman): Everyone in IKEv1 has GUI that lets them pick what
they want. No  consistent defaults. People are really using DES, because it
is mandatory to implement in  IKEv1. Upgrade cannot be direct, because we
won't support DES going forward.

Comment: Need more active discussion on peer addresses than just a few
comments, or we won't  handle the problem.

Comment (Radia Perlman): Curious whether there is passion behind suites?
Charlie: Only losing  side shows up. Ted: 80% of room in Atlanta wanted
suites. Charlie: heard requirement to  negotiate any combination in IKEv1.
Russ: Charlie's story: two bales of hay and a donkey.  Donkeys are not too
dumb not to decide which to eat from.

Comment: WG list came to consensus with a la carte suites. VPNID is just
another name, and we  don't need to do anything about it. Just agree upon a
name; just use them.

Comment: (Paul Hoffman) 80% people speaking did not support suites, but the
vote was 80%.  Developers more evenly split on a la carte.

Comment: v1 has a la carte, and it ain't broke

Comment: What happened to discussion about GUIs?

Charlie: Asked a la carte party which a la carte they want. The question of
"ands" and "ors"  has to be addressed. Changing is tiresome. There is always
consensus we can make it better

Uri: main reason to have a la carte is it is simpler. main reason to have
suites is it is  analyzable. This is the main reason to select a la carte.

Comment: In the protocol define as a la carte but draft 3 suites. This gives
benefits of both.  3 is the right number for interoperability testing.

Charlie: Can do this; a la carte text is escrowed.

Ted: We don't want to debate this one. Current draft: 5; some form of a la
carte: 25; some  form of a la carte in v2 '02 draft v v1 encoding scheme:
unanimous in favor of v2 '02.

Ted: we need to lock this decision in stone.

Ted: Want consensus that we won't do QoS, outsourced VPN, mobility support
in a new WG.  Everyone agrees.

9. Kill off me-Tarzan-you-Jane:

argument for: initiator id sufficient to demux multiple VPNs.

Comment: But this is not a problem for VPNs. It is a problem for end-to-end
use. Don't know  what it means to remove it.

Comment: Right. Keep me-Tarzan-you-Jane, because useful outside of VPN.

Comment: But do we need two different payloads to do same thing? What we
need to kill off is  optional ID payload.

Comment: No. The way the initiator wants to refer to responder identity
might not be a raw  key. Better to use identity name space rather than key
name space. Need to keep identity  across key roll-over.

Comment: Can't use CERTREQ with anything other than PKIX signing certs.

Comment: But then why do we have these other types?

Comment: Other types need to be specified; no semantics for them.

Comment: Can express remote identity by certificate you want to receive. You
will get that  certificate. We will always do this, so always pass
certificate chains. We won't get the  performance optimization we thought.
We need a bit saying whether the ID payload refers to  requestor or
responder. Requirement to specify remote end is a non-negotiable
requirement.  CERTREQ is for getting certs. This is premature optimization.

Charlie: There is confusion. Me-Tarzan-You-Jane solves one problem, but
people try to solve  other problems, but doesn't work there, so want to
remove it. If you don't use it to solve the  wrong problem, it is fine and
shouldn't be used.

Comment (Derek Atkins): Keep what's there.

Comment (Dan Harkins): Payload is not non-critical. It is a mandatory
option. The problem it  solves is never stated.

Ted: How many believe current language be kept? Removed? Don't care? Vote
was to keep it. If  you want it clarified, send text to Charlie.

10. Revised identity

Is there anything left to do?

Paul Hoffman: Charlie clarified when to send cert. Only open issue is to
define what identity  means. Do we want to clarify this?

Comment: Tarzan-Jane discussion arose because of no identity notion.

Comment: We don't know how to build certificates for IKE. We can't change
PKIX. Does ID  payload contents need to match something in CERT payload? Can
solve this problem with one  sentence. Need to make this explicit to close
this issue.

Charlie: Devil is in details. Yes they have to match, but we don't know what
matching means.

Ted: In Kerberos, you specify name, ticket, and access control check. This
problem is never  addressed in Kerberos. Similarly in SSH. Because of Cert
structure, people think they don't  have to check access control list but
rather only check some magical field in cert. Interop  problems arise from
this. Draft haven't done this.

Paul: Can't decide this in IKEv2 timeframe. Let's defer it.

Comment: Don't want to go through same as last 4 years.

Comment: There are implementations that check ACL. Name is just a hint to
find right key.  People are looking for way to contact random machine and
make decisions.

Steve Kent: Agree with Paul; too complicated to get resolved. There is an
ACL; it is the SPD.  Problem people run into is we haven't nailed down SPD
syntax well enough to remove these  problems. Intent was precisely to
establish entries in form that cert will map to SPD entries.  This is a
2401bis problem

Comment: Two issues: access policy, which is user's decision.
Interoperability problems  because of configuration. Not trying to solve
these problems which is protocol  interoperability. What we need to insure
is protocol interoperability: do you have to match  something in cert to
something in ID payload or not.

Comment: Try: "after you have authenticated the dude on the other end, you
MUST decide whether  this matches the access control criteria on your end."

Comment: Deal with this in 2401bis. Short term solution is to say that what
goes in ID v CERT  payload is a local matter for now. It need not match.

Comment: SO we will put in sentence that ID payload is for policy lookup and
does not need to  match anything in CERT payload. Both fields may be used
for access control decisions, but need  not be correlated. 2-1 in favor.

Steve Kent: Don't think this clarifies anything, other than allows a vendor
to claim  compliance. It doesn't solve the problem.

Ted: alternate proposal?

Paul Hoffman: Do this on the list. What implementers claim their
implementations do doesn't  match debug log.

Comment: We have opened can of worms best closed on list.

11. DHCP v. CFG payload

Summary: Both solutions are technically workable. IKEv2-05 allows server to
refuse CFG request  and uses fallback to 3456bis. DHCP encapsulation within
IKE recent submission.

DHCP encapsulation might be suitable compromise, but not fleshed out. If
consensus in WG to  pursue this new idea, give them limited time, then
decide to fallback to IKEv2-05. If people  want 3456bis, give people short
time to produce text, otherwise fall back to IKEv2-05 CFG  payload. 5 or 6
happy with current, 3 or 4 unhappy.

Comment: growth of DHCP indicates configuration is a hard problem; let
someone solve it. That  speaks to just reusing DHCP. Don't reinvent the
wheel; just use DHCP. Pursue this with a  reasonable timeout with fallback.

Comment: CFG payload has fallback mechanism built in for implementations
that want to do  something else. Keep CFG payload as is to allow DHCP or
whatever else.

Comment: Getting into trouble with IPv6. Already have several, creating yet
another one.

Comment: DHCP INFORM gives options not given by CFG payload. This would
satisfy problems.  Yeah; we do need to think more about v6.

Comment: Makes sense to give DHCP 3 weeks to flesh out document.

Comment: DHCP is still evolving. CFG payload would not allow use of DHCP
end-to-end security.  In many cases DHCP options influence address
assignment, so need this information before CFG  payload. Better to restrict
ourselves to one way.

Comment: Alternative scenario. Authentication might influence address
assignment. Push to  restrict this to bootstrap and not generalize it. DHCP
is not interoperable in terms of  options.

Comment: Not clear how DHCP will work with RADIUS or LDP; CFG option
superior for this.

Comment: Security Gateway acts as proxy for client; it is responsible for
authentication.

Comment: But this is not end-to-end.

Comment: In DHCP-over-IKE, Server is DHCP relay, not a proxy. There are
proposals to carry EAP  within DHCP, too. While server does have to
interpret DHCP bits, we don't want it to modify  them.

Ted: Seems to be a number of people speaking in favor of allowing
DHCP-over-IKE 3 weeks.  Strong interest in pursuing this?

Comment: in 3 weeks we will compare. Need a few days specifying what
scenarios have to be  addressed.

Comment: More problems being raised now that there is a proposal. IKEv1 was
successful because  (1) there was a freeware implementation as a starting
point and (2) we did interoperability  testing before going to RFC. We are
not ready to go to RFC, because we have neither of these.  The nature of the
market is people will believe there is interoperability because it is an
RFC. Need to have something more baked. Need to have a bakeoff first. Need
to seriously  consider doing so before going to RFC.

Ted: Problem space WG says we should go to proposed standard sooner. From
process viewpoint,  we need some way to prevent flip-flop, so implementers
can implementers.

Comment: Flip-flop occurs because we don't understand problem.

Comment: We haven't started IKEv2 implementation. It would be good to have a
discussion about  this to express opinion about draft.

Ted: Let's close on DHCP first before talking about this. Sense of room to
try DHCP-within-IKE  for 3 weeks and fallback to CFG payload if this doesn't
pan out.

Comment: There are a lot of ModeCFG in IKEv1. CFG payload is near to this,
so there will have  to be new code and understanding.

Straw vote: CFG payload, DHCP-within-IKE with fallback, something else:
10-14-0. Too close to  call; take it to the list.

Comment: Let's have straw vote in 3 weeks.

Ted: Michael Richardson is the stuckee. We want to get draft ready for WG
last call by April  15. Goal to publish this as an RFC before Austria IETF.
Issue is whether baking occurs for  draft standard or proposed standard. We
need to have draft locked down, however.

Comment: what happens with 2401bis? Do we want to divorce IKEv2 from
2401bis? are there  linkages?

Ted: Should we publish IKEv2 and 2401bis simultaneous or in serial.

Comment: They should be "simultaneous"

Ted: That's what we did with IKEv1, but caused problems because there were
12 docs.

Comment: The hairball is not as large this time. Not convinced we have
thought through  problems we have solved.

Comment: Sympathize, but we should try the IETF thing. This is a better
goal.

Comment: Companies are under travel restrictions. we should make bakeoff
affordable and easy  to get to.

---

From: Barbara Fraser <[email-masked]>
Date: Wed, 09 Apr 2003 11:50:43 -0700

It appears there are two different deadlines for submission to the 
proceedings on the IETF web site. I saw the April 14th date but there is an 
earlier one,  April 11. I plan to submit the minutes before the April 11 
deadline so please get any corrections to me in the next couple of days.

thanks,
Barb

At 06:18 PM 4/8/2003, Barbara Fraser wrote:
>Here are the minutes from the working group meeting last month. Please 
>send any corrections to me by April 11 so that we can submit them by the 
>April 14 due date. Special thanks to Jesse for taking such detailed notes 
>during the meeting.
>
>Barb