Re: March 2003 IETF WG Minutes

[Barbara Fraser <byfraser@cisco.com>]

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