2.6.4 IP Security Protocol (ipsec)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-22

Chair(s):
Barbara Fraser <byfraser@cisco.com>
Theodore Ts'o <tytso@mit.edu>
Security Area Director(s):
Jeffrey Schiller <jis@mit.edu>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Jeffrey Schiller <jis@mit.edu>
Technical Advisor(s):
Uri Blumenthal <uri@lucent.com>
Mailing Lists:
General Discussion: ipsec@lists.tislabs.com
To Subscribe: ipsec-request@lists.tislabs.com
Archive: ftp://ftp.tis.com/pub/lists/ipsec OR ftp.ans.net/pub/archive/ipsec
Description of Working Group:
Note: The Technical Advisor has the task to advice on technical matters related to all the MIB work in this WG.

Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security Protocol Working Group (IPSEC) will develop mechanisms to protect client protocols of IP. A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality.

The IPSEC working group will restrict itself to the following short-term work items to improve the existing key management protocol (IKE) and IPSEC encapsulation protocols:

1. Changes to IKE to support NAT/Firewall traversal

2. Changes to IKE to support SCTP

3. New cipher documents to support AES-CBC, AES-MAC, SHA-2, and a fast AES mode suitable for use in hardware encryptors

4. IKE MIB documents

5. Sequence number extensions to ESP to support an expanded sequence number space.

6. Clarification and standardization of rekeying procedures in IKE.

The working group will also update IKE to clarify the specification and to reflect implementation experience, new requirements, and protocol analysis of the existing protocol. The requirements for IKE V2 will be revised and updated as the first step in this process.

Goals and Milestones:
Done  Post as an Internet-Draft the IP Security Protocol.
Done  Post as an Interenet-Draft the specification for Internet key management.
Done  Submit the Internet Key Management Protocol to the IESG for consideration as a Proposed Standard.
Done  Conduct initial interoperability testing of Encapsulating Security payload (ESP) and Authentication Header (AH).
Done  Submit revised Interent-Drafts for ESP, AH, and IP Security Architecture.
Done  Submit revised Internet-Drafts of IP Security Architecture, ESP, and AH to the IESG for consideration as Draft Standards.
Done  Submit Internet-Draft of the Internet Key Management Protocol (IKMP) based on ISAKMP/Oakley to the IESG for consideration as a Proposed Standard.
Done  Submit Internet-Draft of Internet Key Management Protocol to the IESG for consideration as a Proposed Standard.
OCT 01  Internet Drafts on NAT and Firewall traversal, IKE MIBs, and requirements for IPsec and IKE for use with SCTP, to working group last call.
OCT 01  Submit revised Internet-Drafts of NAT and Firewall traversal, IKE MIBs, and SCTP support for considerations as Draft Standards.
NOV 01  Internet-Drafts on sequence number expansion in IKE, and IKE re-keying completed.
DEC 01  Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE re-keying to working group last call.
DEC 01  Internet-Draft on IKE v2 Requirements to working group last call
DEC 01  Internet-Drafts describing candidate IKE v2 approaches submitted to the working group.
FEB 02  Submit revised Internet-Drafts on AES/SHA-2, sequence number expansion, and IKE rekeying for consideration as Draft Standards.
APR 02  Discuss and select the IKE v2 design from candidate approaches.
SEP 02  IKE
DEC 02  Submit
Internet-Drafts:
  • - draft-ietf-ipsec-esp-v3-04.txt
  • - draft-ietf-ipsec-doi-tc-mib-07.txt
  • - draft-ietf-ipsec-ike-ecc-groups-04.txt
  • - draft-ietf-ipsec-flow-monitoring-mib-02.txt
  • - draft-ietf-ipsec-ciph-aes-cbc-04.txt
  • - draft-ietf-ipsec-ike-modp-groups-05.txt
  • - draft-ietf-ipsec-sctp-04.txt
  • - draft-ietf-ipsec-nat-reqts-04.txt
  • - draft-ietf-ipsec-nat-t-ike-05.txt
  • - draft-ietf-ipsec-udp-encaps-06.txt
  • - draft-ietf-ipsec-dpd-02.txt
  • - draft-ietf-ipsec-properties-02.txt
  • - draft-ietf-ipsec-ikev2-05.txt
  • - draft-ietf-ipsec-ciph-aes-xcbc-mac-03.txt
  • - draft-ietf-ipsec-ciph-sha-256-01.txt
  • - draft-ietf-ipsec-jfk-04.txt
  • - draft-ietf-ipsec-rfc2402bis-02.txt
  • - draft-ietf-ipsec-revised-identity-00.txt
  • - draft-ietf-ipsec-soi-features-01.txt
  • - draft-ietf-ipsec-pki-profile-02.txt
  • - draft-ietf-ipsec-esn-addendum-00.txt
  • - draft-ietf-ipsec-ciph-aes-ctr-03.txt
  • - draft-ietf-ipsec-ikev2-ecnfix-01.txt
  • - draft-ietf-ipsec-ciph-aes-ccm-02.txt
  • - draft-ietf-ipsec-ikev2-tutorial-01.txt
  • Request For Comments:
    RFCStatusTitle
    RFC1829 PS The ESP DES-CBC Transform
    RFC1827 PS IP Encapsulating Security Payload (ESP)
    RFC1828 PS IP Authentication using Keyed MD5
    RFC1826 PS IP Authentication Header
    RFC1825 PS Security Architecture for the Internet Protocol
    RFC2104 I HMAC: Keyed-Hashing for Message Authentication
    RFC2085 PS HMAC-MD5 IP Authentication with Replay Prevention
    RFC2401 PS Security Architecture for the Internet Protocol
    RFC2410 PS The NULL Encryption Algorithm and Its Use With IPsec
    RFC2411 I IP Security Document Roadmap
    RFC2402 PS IP Authentication Header
    RFC2412 I The OAKLEY Key Determination Protocol
    RFC2451 PS The ESP CBC-Mode Cipher Algorithms
    RFC2403 PS The Use of HMAC-MD5-96 within ESP and AH
    RFC2404 PS The Use of HMAC-SHA-1-96 within ESP and AH
    RFC2405 PS The ESP DES-CBC Cipher Algorithm With Explicit IV
    RFC2406 PS IP Encapsulating Security Payload (ESP)
    RFC2407 PS The Internet IP Security Domain of Interpretation for ISAKMP
    RFC2408 PS Internet Security Association and Key Management Protocol (ISAKMP)
    RFC2409 PS The Internet Key Exchange (IKE)
    RFC2857 PS The Use of HMAC-RIPEMD-160-96 within ESP and AH

    Current Meeting Report

    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.
    
    
    

    Slides

    Agenda
    Working Group Draft Status
    IKEv2 Configuration Payload Integration
    Update on ESP v2 & AH v2 and a Word on 2401bis
    DHCP-over-IKE
    IKE V2 Open Issues