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 names.
    
ID Status
    AES Related Drafts
        draft-ietf-ipsec-ciph-aes-xcbc-mac-02.txt
            in IESG wait (AD writeup)
        draft-ietf-ike-modp-groups-04.txt
            in IESG wait (AD writeup)
        draft-ietf-ipsec-ciph-sha-256-01.txt
            not going to be advanced
        draft-ietf-ipsec-ciph-aes-cbc-04.txt
            submitted for IETF last call
    Extended sequence number docs
        draft-ietf-ipsec-esp-v3-03.txt
            ready for wg last call (one last round of editing by authors)
        draft-ietf-ipsec-rfc2402bis-01.txt
            ready for wg last call (one last round of editing by authors)
        draft-ietf-ipsec-esn-addendum-00.tx
            ready for wg last call
    NAT Traversal docs
        draft-ietf-ipsec-udp-encaps-04.txt
            ready for IETF last call for proposed standard
        draft-ietf-ipsec-nat-t-ike-04.txt
            ready for IETF last call for proposed standard
        draft-ietf-ipsec-udp-encaps-justification-01.txt
            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
        draft-ietf-ipsec-doi-tc-mib-06.txt
        draft-ietf-ipsec-flow-monitoring-mib-02.txt
        draft-ietf-ipsec-ike-monitor-mib-04.txt
        draft-ietf-ipsec-isakmp-di-mon-mib-05.txt
        draft-ietf-ipsec-monitor-mib-06.txt
    Others
        draft-ietf-ipsec-ike-ecc-groups-04.txt
            Moribund; no WG interest
        draft-ietf-ipsec-sctp-04.txt
            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
    draft-jacobs-signaling-security-requirements
    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
    http://www.ee.technion.ac.il/~hugo/sigma.ps
    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 requirements
    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 acceleration
        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 deployment
    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 authentication
    If we make IPv6 always use IPsec, it will appear to be more secure
    Security policy should be maintained by an external trusted third party
    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 factory?
    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 sizes
        Instead, use a random or uniform field in the initial counter
            Shrink the SPI field
            Won't allow protection of jumbograms
    Comparison
        Table showed comparison of equivalent strengths
        Asked for limits of memory, some disagreement was heard
        Requires a very, very rich advisory
    Questions
        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
        Options
            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 carte
    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 themselves
                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 mechanism.
        Phil Hallam-Baker- Must work with NATs or don't bother.  We should think about keys, not certs. Get rid of policy from key negotiation.
        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 certificate.
        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, 2003.
        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 4/6.
        Barbara Fraser wanted to have a meeting about legacy authentication this week.
        Gregory Lebovitz - Are we also including remote configuration?
        Jeff Schiller - Can you decided suites vs. ala carte in 4 minutes?
        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 algorithm.
        Magnus Nystrom - Prefers suites because of interaction between algorithms.
        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.