Current Meeting Report
Jabber Logs

2.6.3 IP Security Protocol (ipsec)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 05/16/2002

Barbara Fraser <>
Theodore Ts'o <>
Security Area Director(s):
Jeffrey Schiller <>
Steve Bellovin <>
Security Area Advisor:
Jeffrey Schiller <>
Technical Advisor(s):
Uri Blumenthal <>
Mailing Lists:
General Discussion:
To Subscribe:
Archive: OR
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.
DEC 02  Submit
  • - draft-ietf-ipsec-esp-v3-03.txt
  • - draft-ietf-ipsec-ike-ecc-groups-04.txt
  • - draft-ietf-ipsec-ciph-aes-cbc-04.txt
  • - draft-ietf-ipsec-ike-modp-groups-04.txt
  • - draft-ietf-ipsec-sctp-03.txt
  • - draft-ietf-ipsec-nat-reqts-01.txt
  • - draft-ietf-ipsec-nat-t-ike-03.txt
  • - draft-ietf-ipsec-udp-encaps-03.txt
  • - draft-ietf-ipsec-properties-02.txt
  • - draft-ietf-ipsec-ciph-sha-256-01.txt
  • - draft-ietf-ipsec-ikev2-02.txt
  • - draft-ietf-ipsec-jfk-04.txt
  • - draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt
  • - draft-ietf-ipsec-ikev2-rationale-00.txt
  • - draft-ietf-ipsec-rfc2402bis-01.txt
  • - draft-ietf-ipsec-sonofike-rqts-00.txt
  • - draft-ietf-ipsec-revised-identity-00.txt
  • - draft-ietf-ipsec-soi-features-01.txt
  • - draft-ietf-ipsec-pki-profile-00.txt
  • - draft-ietf-ipsec-esn-addendum-00.txt
  • - draft-ietf-ipsec-ciph-aes-ctr-00.txt
  • Request For Comments:
    RFC1827 PS IP Encapsulating Security Payload (ESP)
    RFC1828 PS IP Authentication using Keyed MD5
    RFC1829 PS The ESP DES-CBC Transform
    RFC1826 PS IP Authentication Header
    RFC1825 PS Security Architecture for the Internet Protocol
    RFC2085 PS HMAC-MD5 IP Authentication with Replay Prevention
    RFC2104 I HMAC: Keyed-Hashing for Message Authentication
    RFC2402 PS IP Authentication Header
    RFC2451 PS The ESP CBC-Mode Cipher Algorithms
    RFC2401 PS Security Architecture for the Internet Protocol
    RFC2403 PS The Use of HMAC-MD5-96 within ESP and AH
    RFC2412 I The OAKLEY Key Determination Protocol
    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)
    RFC2411 I IP Security Document Roadmap
    RFC2410 PS The NULL Encryption Algorithm and Its Use With IPsec
    RFC2857 PS The Use of HMAC-RIPEMD-160-96 within ESP and AH

    Current Meeting Report

    scenarioss.Minutes for IPsec WG
    November 18, 2002
    Agenda was considered and accepted
    Minutes taker: Paul Hoffman, VPN Consortium
        Apologies in advance for spelling errors, particularly in people's 
    ID Status
        AES Related Drafts
                in IESG wait (AD writeup)
                in IESG wait (AD writeup)
                not going to be advanced
                submitted for IETF last call
        Extended sequence number docs
                ready for wg last call (one last round of editing by 
                ready for wg last call (one last round of editing by 
                ready for wg last call
        NAT Traversal docs
                ready for IETF last call for proposed standard
                ready for IETF last call for proposed standard
                ready for IETF last call for informational RFC
        MIB docs
            Discussion has been non-existent since November.
                Plan to forward all of them to WG last call
                Moribund; no WG interest
                Proposed standard
                IESG wait (point raised by some AD; awaiting writeup)
        DPD draft - to WG last call soon
        IPsec properties - prepared to help with SOI
            Needs more work to be publishable
            Andrew wants to do work
            Ted and Barb view as a distraction
    VoIP Security Requirements - Eric Nielsen
        VoIP is really across many protocols
        How can they leverage IPsec as the underlying security mechanism?
        Describes the view of a consumer of IPsec
        Please review it
    SIGMA paper announcement - Hugo Krawczyk
        New paper was published
        Gives the crypto rationale for IKEv1 signature modes and IKEv2 
    cryptographic key exchange.
        Covered ancient history (1995-1996) regarding the development of SIGMA 
    and its inclusion in IKE
        Summary: don't just do a signature, also MAC the identity of the 
    signer (the MAC is essential for the key exchange security!).
        This paper is informal and intended to a broad audience of 
    designers and practitioners. A formal mathematical analysis was done in a 
    paper with Ran Canetti presented at Crypto'2002.
    PKI profile draft - Brian Korver
        Profile PKIX for IKE
        Compliments IKE
        -00 and -01 were straw proposals
        Types of issues
            CRL processing
            Empty CERTREQ
            Using ID payload for policy
            Which fields in the cert should be used as ID
            Out of band exchange of keying material
        Want comments for -02
        Gregory Lebovitz - Project DPloy earlier this year did much of the 
        Paul Hoffman talked about previous document in this space. This 
    should not make IKEv1 implementations non-conformant. Brian said he 
    wasn't sure how he wanted it to apply to v1 or v2
        Michael Richardson - thinks it should apply to IKEv1 and IKEv2
    Digital signatures for ESP and AH - Brian Weis
        Main need for this is source origin authentication
        This is needed for multicast or anycast
        ESP and AH don't specify any particular authentication mechanism, they 
    just say where to do it.
        Digital signatures are very well understood
        RSA is widely implemented and is free
            Also fast for verification, which is good in multicast because the 
    receivers do less work
        Still some issues
            Authentication data is larger
            Performance is big issue, but not so much if you have hardware 
            DoS vulnerability: RSA verification is much slower than HMAC
        Bill Sommerfeld - Key size needs to be balanced against how long you are 
    going to use the key
        Hilarie Orman - It's about time! The demultiplexing is done in a 
    different place. And why not use elliptic curves?
        Andrea Colegrove - How do you tell IPsec who can send (and 
    therefore sign) the messages?
        Is this of interest to the WG?
    IPv6 and IPsec Deployment Issues - Tomoaki KOBAYAKAWA
        Deployment scenario, not a proposal for a solution
        Need a solution in order to help IPv6 get deployed
        IPv6 deployment status
            Definitely been deployed, especially in Japan
            Lots of home appliances using it
            But many IPv4 users think that IPv4 is enough
            If IPv6 is cheaper than IPv4, it will cause greater IPv6 
        IPv6 plug-and-play can be help
        Authentication can come from the ISP instead of from the end user, 
    making devices and games easier to start from scratch
        IPv6 autoconf can also help with sensors and devices that need strong 
        If we make IPv6 always use IPsec, it will appear to be more secure
        Security policy should be maintained by an external trusted third 
        PKI avoidance is good
        Need plug-and-play IPsec for IPv6 for peer-to-peer, so please think 
    about proposals
        Hugh Daniel - Won't buy a device that he cannot set the keys in
        Scott Fanning - How do you get a credential for a device from the 
        Steve Bellovin - Doubts about plug-and-play because the lack of 
    authorization. How would an ISP know who is the end user for 
    connecting particular devices?
        Charlie Kaufman - Protect against passive eavesdropping but others in 
    the crypto field don't want this
        Gregory Lebovitz - Consumer devices already have less security and 
    people buy it all the time
        Eric Nielsen - VoIP has similar problems of weighing the 
    plug-and-play vs. flexibility
        Atsushi Inoue - What is the next step for this proposal? Will you make a 
    key management protocol that matches this? Kobayakawa wants to do this.
    Counter Mode Security Analysis and Recommendations - Dave McGrew
        Wants to raise issues for discussion
        CM can be implemented securely
            Properties are different but not worse
        CM is more vulnerable to some precomputation attacks
            Lacks per-packet random input that CBC has
        Attacker precomputes and stores a database
            Amortizes the computation across many breaks lowering the 
    expected work per break
        Protections against this attack
            It has to be unpredictable to the adversary
            To do this, use a larger key
                Use AES-192 to get 128-bit strength
                This requires more computation and mandates using multiple key 
            Instead, use a random or uniform field in the initial counter
                Shrink the SPI field
                Won't allow protection of jumbograms
            Table showed comparison of equivalent strengths
            Asked for limits of memory, some disagreement was heard
            Requires a very, very rich advisory
            Is 85 or fewer bits of security acceptable?
            Is inability to encrypt jumbograms OK?
            Is it OK to require AES-192 acceptable?
            Is an explicit IV needed?
        For 10 Gbs message authentication, CM is the only 
    non-encumbered system known
        Uri Blumenthal - Not related to the A5 attack. Wants more time to 
    review the numbers to see if this is really an 85-bit attack.
        Russ Housley - Appreciates bringing the issue to the wider group.
            Ron Rivest said just the longer key.
        Ted Ts'o - Wants people who know crypto to help analyze whether it is 
    really a practical attack.
    IKEv2 status discussion - Charlie Kaufman
        New draft in October
        Changed many things that became controversial:
            Suites replaced ala carte
            Went to always 4 messages
            Simplified traffic selector (no one has complained)
        Other controversies
            NAT traversal
            Tunnel vs. transport negotiation
            Key sizes and algorithms
            Legacy auth not covered
            Revised identity proposal
        NAT Traversal
            Not in IKEv1, but now there is a draft
            Should the new extensions be included in IKEv2?
        Tunnel vs. transport
            No negotiation in IKEv2
            Charlie needs to understand why this is needed
            If inner and outer IP addresses are the same,
                MAY use transport
        MUST key size and algorithms
            1024 vs. 1023 bit keys
            It's hard to have this debate until we know suites vs. ala carte
        Number of messages
            4 messages except a few cases
            Always-4 is more complicated to be stateless
            Messages are larger, which causes UDP fragmentation issues
            May impact legacy authentication
                CRACK-style does better with 4/6 than with always-4
        Legacy authentication
            Road warrior configurations
                Passwords, SecureID, challenge-response cards, etc.
                All have subtle differences
            History includes, XAUTH, CRACK, PIC
            Use legacy auth to get a cert
                Recursion problem
                Need a PKI
            What to do
                Ignore it -- not
                Don't hold up IKEv2: do it later
                Use password as a shared key
                    Has dictionary attack
                Design it in
                    Reference an existing multiplexer like SASL/EAP or GSSAPI
                    Modify one of the IKEv1 solutions
                    Start over
        Suites vs. ala carte
            IKEv1: propose a subset and responder selects
            Old IKEv2: same things but with a better encoding
            JFK: responder decrees
            Current IKEv2: defines suites, responder selects
            Why people like suites
                Easier to implement if the number is manageable
            Why people like ala carte
                Easier to implement if the number is large
                Easier to add new parts
                Leave it as suites
                Change it back to ala carte
                Cleverly-chosen multi-byte suite IDs
                Do both: MUST do suites but can do ala carte
                    Only good idea if believe many implementations don't do ala 
        Revised identity
            Several proposals wrapped together
                CERTREQ renamed TrustedRoot
                    Used to listing trust anchors
                    Instead of DN of trust anchor, use SHA1 of public key
                    Charlie wants to copy TLS
                Allow URLs to certificates instead of the certs 
                    Some certs are very large
                    The other end might know it
                    But can't always use the URL
                    What are the MUST/MAY/SHOULDs to guarantee interop
                Negotiate authentication algorithms
                    New IDAccepted field
                    Needed if there are multiple ways that you are capable of 
    authenticating and want to autoselect
                Merge ID and CERT into FullID
                    Today IDs is required but CERT is optional
                    Unstated what the relation between ID and cert are
                    Whatever is in the cert is the ID: need to translate for 
    your SADB
        OK, how do we become an RFC?
            Choose between multiple bales of hay (bad joke elided)
            Integrate NAT traversal now or later?
            Integrate legacy auth now or later?
            Charlie's preference
                Add some crypto tweaks from Hugo
                Decide now on the choices
                Work on other things in parallel that can be folded into this 
    document if it doesn't hold up the document
            Ted Ts'o - If it is NAT-traversal friendly, we can do that in 
    another document that describes how. If you leave holes in the spec, it has 
    to be filled fast, otherwise a vendor will do it for us and we won't be 
    able to fix it.
            Tero Kivinen - It isn't NAT-traversal friendly now but it can be 
    made so easily.
            David Black - People designing suites have forgotten some 
    things, so we need either ala carte or have a well-defined extension 
            Phil Hallam-Baker- Must work with NATs or don't bother.  We 
    should think about keys, not certs. Get rid of policy from key 
            Hilarie Orman - AA Milne was quoted. Suggested negotiating key 
    policy in protocol from the IP Security Policy WG.
            Eric Rescorla - TLS doesn't negotiate trust anchors at all; this is 
    not a raging success. Maybe assume that you only have one 
            Cheryl Madsen - If we split off items from a single document, we 
    lose momentum and it can take years.
            William Dixon - Noticed that requirements draft died. No one was 
    giving any feedback so there was no interest in a requirements 
    document. The requirements are inherent in the protocol design and on the 
    mailing list, but he wanted to be sure that the WG wanted this.
            Jeff Schiller wearing his AD hat - Rest of the IETF wants to 
    consume this technology soon. It's time. If this effort is to succeed, it 
    must terminate. If this doesn't finish soon, we will terminate the WG and 
    everyone has to use IKEv1.  Wants a timeline that finishes by Feb. 15, 
            Ted Ts'o - We negotiated that date.
            Cheryl Madsen - The scope of IKEv2 is VPNs and remote access.
            William Dixon - What are doing that is different than IKEv1?
            Paul Hoffman - We need remote access or else it looks like IKEv1.
            Jeff Schiller - Can the WG decided between always-4 or 4/6 in the 
    next 15 minutes?
            Paul Hoffman - 4/6 is much better for CRACK-like.
            Michael Richardson - Doesn't care about always-4 or 4/6.  We 
    should embed remote access, just take it from IPSRA.  If we got good cert 
    stuff, we don't need legacy auth, but if we are going to do it, do it now.
            Bill Sommerfeld - Good if we can do always-4 if we don't do 
    legacy auth. This might push against legacy auth.
            Tero Kivinen - NAT traversal is more complicated if we do 
    always-4, but simple to add in 4/6. We need to do port floating.
            Eric Rescorla - Because 4/6 takes less thinking, we should use it.
            Ted Ts'o took a straw poll. Humming happened. The consensus was 
            Barbara Fraser wanted to have a meeting about legacy 
    authentication this week.
            Gregory Lebovitz - Are we also including remote 
            Jeff Schiller - Can you decided suites vs. ala carte in 4 
            David Black and Cheryl Madsen - There is also a way to do a 
    hybrid mechanism.
            William Dixon - Needs to be able to swap in a different 
            Magnus Nystrom - Prefers suites because of interaction between 
            Jeff Schiller - Just decide between suites or ala carte for 
    crypto only; other items will be decided later.
            Ted Ts'o took a straw poll on crypto suite or suites.  Humming 
    happened, but it sounded close. Hands were raised.  The chairs saw three 
    times as many for suites than for ala carte.
            Jeff Schiller asked who cared a great deal about the way that they 
    voted. Only a few hands went up.
    Meeting was adjourned only a few minute over time. Many folks said they 
    would work on the remote access problem, the suites extension issue, NAT 
    traversal, and other problems.


    VoIP Signaling requirements
    SIGMA: the 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols
    The Internet IP Security PKI Profile of ISAKMP and PKIX
    IPv6 and IPsec Deployment Issues
    Counter Mode Security: Analysis and Recommendations
    Son of IKE Status