Subject: [tcpm] draft-ietf-tcpm-tcp-ao-crypto-01, ready for WG LC

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Mon, 26 Oct 2009 19:17:39 -0700

Hey all,
Below pls find pasted the latest version of
    draft-ietf-tcpm-tcp-ao-crypto-01

This one should be ready for WG LC. I'll let the WG Chairs make that call.

It did not include a change log, but here are the changes:
  - simplified title of document - Touch
  - copy edits for read-ability throughout - Touch
  - switched "Derived_Key" back to "Traffic_Key" in order to sync 
with -AO spec.
  - added the two IANA values SHA1 and AES128 to IANA section

I missed the cutoff for I-D submission, but have asked Lars (AD) to 
intervene. Hopefully he can get it published to the repository with a 
manual push.

Gregory.

At 07:12 PM 10/26/2009, you wrote:
>Attached are the .txt and .xml for the version of 
>draft-ietf-tcpm-tcp-ao-crypto-01 document, which should be ready for 
>WG Last Call. It contains all the latest feedback from reviews by 
>Touch and EKR. I missed the I-D deadline by 2 hours...  ughh. The 
>text of  the draft is pasted below, for convenience.
>
>Lars, can you push this through the I-D editor queue for us??
>
>Gregory.
>= = = = BEGIN PASTED TEXT; view in fixed width font = = = =
>
>
>
>TCPM                                                         G. Lebovitz
>Internet-Draft                                                   Juniper
>Intended status: Standards Track                             E. Rescorla
>Expires: April 29, 2010                                             RTFM
>                                                         October 26, 2009
>
>
>     Cryptographic Algorithms for TCP's Authentication Option, TCP-AO
>                     draft-ietf-tcpm-tcp-ao-crypto-01
>
>Status of this Memo
>
>    This Internet-Draft is submitted to IETF in full conformance with the
>    provisions of BCP 78 and BCP 79.  This document may contain material
>    from IETF Documents or IETF Contributions published or made publicly
>    available before November 10, 2008.  The person(s) controlling the
>    copyright in some of this material may not have granted the IETF
>    Trust the right to allow modifications of such material outside the
>    IETF Standards Process.  Without obtaining an adequate license from
>    the person(s) controlling the copyright in such materials, this
>    document may not be modified outside the IETF Standards Process, and
>    derivative works of it may not be created outside the IETF Standards
>    Process, except to format it for publication as an RFC or to
>    translate it into languages other than English.
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups.  Note that
>    other groups may also distribute working documents as Internet-
>    Drafts.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time.  It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt.
>
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
>
>    This Internet-Draft will expire on April 29, 2010.
>
>Copyright Notice
>
>    Copyright (c) 2009 IETF Trust and the persons identified as the
>    document authors.  All rights reserved.
>
>
>
>
>Lebovitz & Rescorla      Expires April 29, 2010                 [Page 1]
>
>Internet-Draft              Crypto for TCP-AO               October 2009
>
>
>    This document is subject to BCP 78 and the IETF Trust's Legal
>    Provisions Relating to IETF Documents in effect on the date of
>    publication of this document (http://trustee.ietf.org/license-info).
>    Please review these documents carefully, as they describe your rights
>    and restrictions with respect to this document.
>
>Abstract
>
>    The TCP Authentication Option, TCP-AO, relies on security algorithms
>    to provide authentication between two end-points.  There are many
>    such algorithms available, and two TCP-AO systems cannot interoperate
>    unless they are using the same algorithm(s).  This document specifies
>    the algorithms and attributes that can be used in TCP-AO's current
>    manual keying mechanism.
>
>
>Table of Contents
>
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
>    2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  3
>      2.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
>      2.2.  Algorithm Requirements . . . . . . . . . . . . . . . . . .  3
>      2.3.  Requirements for Future MAC Algorithms . . . . . . . . . .  4
>    3.  Algorithms Specified . . . . . . . . . . . . . . . . . . . . .  4
>      3.1.  Key Derivation Functions (KDFs)  . . . . . . . . . . . . .  5
>        3.1.1.  Concrete KDFs  . . . . . . . . . . . . . . . . . . . .  6
>      3.2.  MAC Algorithms . . . . . . . . . . . . . . . . . . . . . . 10
>        3.2.1.  The Use of HMAC-SHA-1-96 . . . . . . . . . . . . . . . 11
>        3.2.2.  The Use of AES-128-CMAC-96 . . . . . . . . . . . . . . 11
>    4.  Change History (RFC Editor: Delete before publishing)  . . . . 12
>    5.  Needs Work in Next Draft (RFC Editor: Delete Before
>        Publishing)  . . . . . . . . . . . . . . . . . . . . . . . . . 14
>    6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
>    7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
>    8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
>    9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
>      9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
>      9.2.  Informative References . . . . . . . . . . . . . . . . . . 16
>    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
>
>
>
>
>
>
>
>
>
>
>
>
>Lebovitz & Rescorla      Expires April 29, 2010                 [Page 2]
>
>Internet-Draft              Crypto for TCP-AO               October 2009
>
>
>1.  Introduction
>
>    This document is a companion to TCP-AO [TCP-AO]
>    [I-D.ietf-tcpm-tcp-auth-opt].  Like most modern security protocols,
>    TCP-AO allows users to chose which cryptographic algorithm(s) they
>    want to use to meet their security needs.
>
>    TCP-AO provides cryptographic authentication and message integrity
>    verification between to end-points.  In order to accomplish this
>    function, message authentication codes (MACs) are used, which then
>    rely on shared keys.  There are various ways to create MACs.  The use
>    of hashed-based MACs (HMAC) in Internet protocols is defined in
>    [RFC2104].  The use of cipher-based MACs (CMAC) in Internet protocols
>    is defined in [RFC4493].
>
>    This RFC defines the general requirements for MACs used in TCP-AO,
>    both for currently specified MACs and for any future specified MACs.
>    It then specifies two MAC algorithms required in all TCP-AO
>    implementations.  It also specifies two key derivations functions
>    (KDFs) used to create the traffic keys used by the MACs.  These KDFs
>    are also required by all TCP-AO implementations.
>
>
>2.  Requirements
>
>2.1.  Requirements Language
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].
>
>    When used in lower case, these words convey their typical use in
>    common language, and are not to be interpreted as described in
>    [RFC2119].
>
>2.2.  Algorithm Requirements
>
>    This is the initial specification of required cryptography for
>    TCP-AO, and indicates two MAC algorithms and two KDFs.  All four
>    components MUST be implemented in order for the implementation to be
>    fully compliant with this RFC.
>
>    The following table indicates the required MAC algorithms and KDFs
>    for TCP-AO:
>
>
>
>
>
>
>
>Lebovitz & Rescorla      Expires April 29, 2010                 [Page 3]
>
>Internet-Draft              Crypto for TCP-AO               October 2009
>
>
>            Requirement      Authentication Algorithm
>            ------------     ------------------------
>            MUST             HMAC-SHA-1-96 [RFC2404]
>            MUST             AES-128-CMAC-96 [RFC4493]
>
>            Requirement      Key Derivation Function (KDF)
>            -------------    ------------------------
>            MUST             KDF_HMAC_SHA1
>            MUST             KDF_AES_128_CMAC
>
>    NOTE EXPLAINING WHY TWO MAC ALGORITHMS WERE MANDATED:
>
>    Two MAC algorithms and two corresponding KDFs are mandated as a
>    result of discussion in the TCPM WG, and in consultation with the
>    Security Area Directors.  SHA-1 was selected because it is widely
>    deployed and currently has sufficient strength and reasonable
>    computational cost, so it is a "MUST" for TCP-AO today.  The security
>    strength of SHA-1 HMACs should be sufficient for the foreseeable
>    future, especially given that the tags are truncated to 96 bits.
>
>    Recently exposed vulnerabilities in other MACs (e.g., MD5 or HMAC
>    MD5) aren't practical on SHA-1, but these types of analyses are
>    mounting and could potentially pose a concern for HMAC forgery if
>    they were significantly improved, over time.  The security issues
>    driving the migration from SHA-1 to SHA-256 for digital signatures
>    [HMAC-ATTACK] do not immediately render SHA-1 weak for this
>    application of SHA-1 in HMAC mode.
>
>    AES-128 CMAC is considered to be a stronger algorithm than SHA-1, but
>    may not yet have very wide implementation.  AES-128 CMAC is also a
>    "MUST" to implement, in order to drive vendors toward its use, and to
>    allow for another MAC option, if SHA-1 were to be compromised.
>
>2.3.  Requirements for Future MAC Algorithms
>
>    TCP-AO is intended to support cryptographic agility.  As a result,
>    this document includes recommendations in various places for future
>    MAC and KDF algorithms when used for TCP-AO.  For future MAC
>    algorithms specifically, they SHOULD protect at least 2**48 messages
>    with a collision probability of less than one in 10**9.
>
>    [Reviewers: Are there any other requirements we want/need to place in
>    here?  RFC EDITOR: Please delete this note before publishing as RFC]
>
>
>3.  Algorithms Specified
>
>    TCP-AO requires two classes of cryptographic algorithms used on a
>
>
>
>Lebovitz & Rescorla      Expires April 29, 2010                 [Page 4]
>
>Internet-Draft              Crypto for TCP-AO               October 2009
>
>
>    particular connection, and refers to this document to define them
>    both:
>
>
>        (1)  Key Derivation Functions (KDFs) which name a pseudorandom
>             function (PRF) and use a Master_Key and some connection-
>             specific input with that PRF to produce Traffic_Keys, the
>             keys suitable for authenticating and integrity checking
>             individual TCP segments, as described in TCP-AO.
>        (2)  Message Authentication Code (MAC) algorithms which take a
>             key and a message and produce an authentication tag which
>             can be used to verify the integrity and authenticity of
>             those messages.
>
>    In TCP-AO, these algorithms are always used in pairs.  Each MAC
>    algorithm MUST specify the KDF to be used with that MAC algorithm.
>    However, a KDF MAY be used with more than one MAC algorithm.
>
>3.1.  Key Derivation Functions (KDFs)
>
>    TCP-AO's Traffic_Keys are derived using KDFs.  The KDFs used in TCP-
>    AO's current manual keying have the following interface:
>
>        Traffic_Key = KDF_algo(Master_Key, Context, Output_Length)
>
>    where:
>
>
>       - KDF_algo:    the specific pseudorandom function (PRF) that is
>                      the basic building block used in constructing the
>                      given Traffic_Key.
>
>       - Master_Key:  In TCP-AO's manual key mode, this is a key shared
>                      by both peers, entered via some interface to their
>                      respective configurations.  The Master_Key is used
>                      as the seed for the KDF.  We assume that this is a
>                      human-readable pre-shared key (PSK), thus we assume
>                      it is of variable length.  Master_Keys SHOULD be
>                      random, but might not be (e.g., badly chosen by the
>                      user).
>
>       - Context :    A binary string containing information related to
>                      the specific connection for this derived keying
>                      material.  TCP-AO specifies the content of the
>                      Context, which includes things like the TCP segment
>                      prepended by the TCP pseudoheader and TCP header
>                      options, as defined in
>                      [I-D.ietf-tcpm-tcp-auth-opt], Section 7.2]
>
>
>
>Lebovitz & Rescorla      Expires April 29, 2010                 [Page 5]
>
>Internet-Draft              Crypto for TCP-AO               October 2009
>
>
>
>       - Output_Length:  The length in bits of the key that the KDF will
>                      produce.  This length must be the size required for
>                      the MAC algorithm that will use the PRF result as a
>                      seed.
>
>    When invoked, a KDF generates a string of length Output_Length bits
>    based on Master_Key and context value.  This result may then be used
>    as a cryptographic key for any algorithm which takes an Output_Length
>    length key.  A KDF MAY specify a maximum Output_Length parameter.
>
>3.1.1.  Concrete KDFs
>
>    This document defines two KDF algorithms, each paired with a
>    corresponding PRF algorithm as explained below:
>
>
>        *  KDF_HMAC_SHA1  based on PRF-HMAC-SHA1 [RFC2404]
>        *  KDF_AES_128_CMAC  based on AES-CMAC-PRF-128 [RFC4615]
>
>
>    Each
>
>    Both of these KDFs are based on the iteration mode KDFs specified in
>    [NIST-SP800-108].  This means that they use an underlying
>    pseudorandom function (PRF) with a fixed-length output lengths, 128
>    bits in the case of the AES-CMAC, and 160 bits in the case of HMAC-
>    SHA1.  The KDF generates an arbitrary number of output bits by
>    operating the PRF in a "counter mode", where each invocation of the
>    PRF uses a different input block differentiated by a block counter.
>
>    Each input block is constructed as follows:
>
>         ( i || Label || Context || Output_Length)
>
>       Where
>
>       - "||":      For any X || Y, "||" represents a concatonation
>                    operation of the binary strings X and Y.
>
>       - i:         A counter, a binary string that is an input to each
>                    iteration of the PRF in counter mode.  The number of
>                    iterations will depend on the specific size of the
>                    Output_Length desired for a given MAC.
>
>
>
>
>
>
>
>Lebovitz & Rescorla      Expires April 29, 2010                 [Page 6]
>
>Internet-Draft              Crypto for TCP-AO               October 2009
>
>
>
>       - Label:     A binary string that clearly identifies the purpose
>                    of this KDF's derived keying material.  For TCP-AO we
>                    use the ASCII string "TCP-AO", where the last
>                    character is the capital letter "O", not to be
>                    confused with a zero.  While this may seem like
>                    overkill in this specification since TCP-AO only
>                    describes one call to the KDF, it is included in
>                    order to comply with FIPS 140 certifications.
>
>       - Context :  The context argument provided to the KDF interface,
>                    as described above in Section 3.1 .
>
>       - Output_Length:  The length in bits of the key that the KDF will
>                    produce.  This length must be the size required for
>                    the MAC algorithm that will use the PRF result as a
>                    seed.
>
>    The ouput of mutiple PRF invocations is simply concatenated.  For the
>    Traffic_Key, values of multiple PRF invocations are concatenated and
>    truncated as needed to create a Traffic_Key of the desired length.
>    For instance, if one were using KDF_HMAC_SHA1, which uses a 160-bit
>    internal PRF to generate 320 bits of data, one would execute the PRF
>    twice, once with i=0 and once with i=1.  The result would be the
>    entire output of the first invocation concatenated with the second
>    invocation.  E.g.,
>
>           Traffic_Key =
>             KDF_algo(Master_Key, 0 || Label || Context || Output_length) ||
>             KDF_algo(Master_Key, 1 || Label || Context || Output_length)
>
>    If the number of bits required is not an even multiple of the output
>    size of the PRF, then the output of the final invocation of the PRF
>    is truncated as necessary.
>
>3.1.1.1.  KDF_HMAC_SHA1
>
>    For KDF_HMAC_SHA1:
>
>    - PRF:       HMAC-SHA1 [RFC2404].
>
>    - Use:       HMAC-SHA1(Key, Input).
>
>    - Key:       Master_Key, configured by user, and passed to the KDF.
>
>
>
>
>
>
>
>Lebovitz & Rescorla      Expires April 29, 2010                 [Page 7]
>
>Internet-Draft              Crypto for TCP-AO               October 2009
>
>
>
>    - Input:     ( i || Label || Context || Output_Length)
>
>    - Output_Length:  160 bits.
>
>    - Result:    Traffic_Key, used in the MAC function by TCP-AO.
>
>3.1.1.2.  KDF_AES_128_CMAC
>
>    For KDF_AES_128_CMAC:
>
>    - PRF:       AES-CMAC-PRF-128 [RFC4615].
>
>    - Use:       AES-CMAC(Key, Input).
>
>    - Key:       Traffic_Master_Key (see below)
>
>    - Input:     ( i || Label || Context || Output_Length)
>
>    - Output_Length:  128 bits.
>
>    - Result:    Traffic_Key, used in the MAC function by TCP-AO
>
>    The Master_Key in TCP-AO's current manual keying mechanism is a
>    shared secret, entered by an administrator.  It is passed via an out-
>    of-band mechanism between two devices, and often between two
>    organizations.  The shared secret does not have to be 16 octets, and
>    the length may vary.  However, AES_128_CMAC requires a key of exactly
>    16 octets (128 bits) in length.  We could mandate that
>    implementations force administrators to input Master_Keys of exactly
>    128 bit length when using AES_128_CMAC, and with sufficient
>    randomness, but this places undue burden on the implementors and
>    deployers.  This specification RECOMMENDS that deployers use a
>    randomly generated 128-bit string as the Master_Key, but acknowledges
>    that deployers may not.
>
>    To handle variable length Master_Keys we use the same mechanism as
>    described in [RFC4615], Sect 3.  First we use AES_128_CMAC with a
>    fixed key of all zeros as a "randomness extractor", while using the
>    shared secret Master_Key, MK, as the message input, to produce a 128
>    bit key Derived_Master_Key (K).  Second, we use the result as a key,
>    and run AES-128_CMAC again, this time using the result K as the Key,
>    and the true input block as the Input to yield the Traffic_Key (TK)
>    used in the MAC over the message.  The description follows:
>
>
>
>
>
>
>
>Lebovitz & Rescorla      Expires April 29, 2010                 [Page 8]
>
>Internet-Draft              Crypto for TCP-AO               October 2009
>
>
> 
>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>    +                        KDF-AES-128-CMAC                           +
>    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>    +                                                                   +
>    + Input  : MK (Master_Key, the variable-length shared secret)       +
>    +        : I (Input, i.e., the input data of the PRF)               +
>    +        : MKlen (length of MK in octets)                           +
>    +        : len (length of M in octets)                              +
>    + Output : TK (Traffic_Key, 128-bit Pseudo-Random Variable)+
>    +                                                                   +
>    +-------------------------------------------------------------------+
>    + Variable: K (128-bit key for AES-CMAC)                            +
>    +                                                                   +
>    + Step 1.   If MKlen is equal to 16                                 +
>    + Step 1a.  then                                                    +
>    +               K := MK;                                            +
>    + Step 1b.  else                                                    +
>    +               K := AES-CMAC(0^128, MK, MKlen);                    +
>    + Step 2.   TK := AES-CMAC(K, I, len);                             +
>    +           return TK;                                             +
>    +                                                                   +
>    +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>
>                                  Figure 1
>
>    In step 1, the 128-bit key, K, for AES-CMAC is derived as follows:
>
>    o If the Master_Key, MK, provided by the administrator is exactly 128
>    bits, then we use it as-is.
>
>    o If it is longer or shorter than 128 bits, then we derive the key K
>    by applying the AES-CMAC algorithm using the 128-bit all-zero string
>    as the key and MK as the input message.  This step is described in
>    step 1b.
>
>    In step 2, we apply the AES-CMAC algorithm again, this time using K
>    as the key and I as the input message.
>
>    The output of this algorithm returns TK, the Traffic_Key, which is
>    128 bits suitable for use in the MAC function on each TCP segment of
>    the connection.
>
>3.1.1.3.  Tips for User Interfaces regarding KDFs
>
>    This section provides suggested representations for the KDFs in
>    implementation user interfaces.  Following these guidelines across
>    common implementations will make interoperability easier and simpler
>
>
>
>Lebovitz & Rescorla      Expires April 29, 2010                 [Page 9]
>
>Internet-Draft              Crypto for TCP-AO               October 2009
>
>
>    for deployers.
>
>    UIs SHOULD refer to the choice of KDF_HMAC_SHA1 as simply "SHA1".
>
>    UIs SHOULD refer to the choice of KDF_AES_128_CMAC as simply
>    "AES128".
>
>    The initial IANA registry values will reflect these two entries.
>
>    UIs SHOULD use KDF_HMAC_SHA1 as the default selection in TCP-AO
>    settings.  KDF_HMAC_SHA1 is preferred at this time because it has
>    wide support, being present in most implementations in the
>    marketplace.
>
>3.2.  MAC Algorithms
>
>    Each MAC_algo defined for TCP-AO has three fixed elements as part of
>    its definition:
>
>    - KDF_Algo:    Name of the TCP-AO KDF algorithm used to generate the
>                   Traffic_Key
>    - Key_Length:  Length in bits required for the Traffic_Key used in
>                   this MAC
>    - Output:      The final length of the bits used in the TCP-AO MAC
>                   field.  This value may be a truncation of the MAC
>                   function's original output length.
>
>    MACs computed for TCP-AO have the following interface:
>
>        MAC = MAC_algo(Traffic_Key, Message)
>
>    where:
>
>
>       - MAC_algo:    MAC Algorithm used
>       - Traffic_Key: Variable; the result of KDF.
>       -  Message     The message to be authenticated, as specified in
>                      [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1.
>
>    This document specifies two MAC algorithm options for generating the
>    MAC as used by TCP-AO:
>
>
>        *  HMAC-SHA-1-96  based on [RFC2404]
>
>
>
>
>
>
>
>Lebovitz & Rescorla      Expires April 29, 2010                [Page 10]
>
>Internet-Draft              Crypto for TCP-AO               October 2009
>
>
>
>        *  AES-128-CMAC-96  based on [RFC4493]
>
>    Both provide a high level of security and efficiency.  The AES-128-
>    CMAC-96 is potentially more efficient, particularly in hardware, but
>    HMAC-SHA-1-96 is more widely used in Internet protocols and in most
>    cases could be supported with little or no additional code in today's
>    deployed software and devices.
>
>    An important aspect to note about these algorithms' definitions for
>    use in TCP-AO is the fact that the MAC outputs are truncated to 96
>    bits.  AES-128-CMAC-96 produces a 128 bit MAC, and HMAC SHA-1
>    produces a 160 bit result.  The MAC output are then truncated to 96
>    bits to provide a reasonable tradeoff between security and message
>    size, for fitting into the TCP-AO header.
>
>3.2.1.  The Use of HMAC-SHA-1-96
>
>    By definition, HMAC [RFC2104] requires a cryptographic hash function.
>    SHA1 will be that has function used for authenticating and providing
>    integrity validation on TCP segments with HMAC.
>
>    The three fixed elements for HMAC-SHA-1-96 are:
>
>    - KDF_Algo:    KDF_HMAC_SHA1.
>    - Key_Length:  160 bits.
>    - Output:      96 bits.
>
>    For:
>
>         MAC = MAC_algo (Traffic_Key, Message)
>
>
>    HMAC-SHA-1-96 for TCP-AO has the following values:
>
>
>       - MAC_algo:    HMAC-SHA1
>       - Traffic_Key: Variable; the result of the KDF.
>       - Message:     The message to be authenticated, as specified in
>                      [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1.
>
>
>
>3.2.2.  The Use of AES-128-CMAC-96
>
>    In the context of TCP-AO, when we say "AES-128-CMAC-96" we actually
>    define a usage of AES-128 as a cipher-based MAC according to
>    [NIST-SP800-38B].
>
>
>
>Lebovitz & Rescorla      Expires April 29, 2010                [Page 11]
>
>Internet-Draft              Crypto for TCP-AO               October 2009
>
>
>    The three fixed elements for AES-128-CMAC-96 are:
>
>    - KDF_Algo:    KDF_AES_128_CMAC.
>    - Key_Length:  128 bits.
>    - Output:      96 bits.
>
>    For:
>
>         MAC = MAC_algo (Traffic_Key, Message)
>
>
>    AES-128-CMAC-96 for TCP-AO has the following values:
>
>
>       - MAC_algo:    AES-128-CMAC-96 [RFC4493]
>       - Traffic_Key: Variable; the result of the KDF.
>       - Message:     The message to be authenticated, as specified in
>                      [I-D.ietf-tcpm-tcp-auth-opt] Section 7.1.
>
>
>
>
>4.  Change History (RFC Editor: Delete before publishing)
>
>    [NOTE TO RFC EDITOR: this section for use during I-D stage only.
>    Please remove before publishing as RFC.]
>
>    draft-ietf...-01 - 5th submission
>
>    o  structure of sect 3 changed: 3.1 becomes "Concrete KDF's" and the
>       description of the two KDF's became 3.1.1.1 & 3.1.1.2. used a
>       template (of sorts) in both sections that can be easily re-used by
>       any future KDF definition.
>    o  in 3.1, for Derived_Key definition, changed the name of the
>       element "Input" to "Context", and removed the hard binding to
>       NIST-SP800-108 at the generic interface level.  The NIST inclusion
>       is still present in the concrete definitions of the two presented
>       KDF's, but this way, if NIST changes, or if the community wants to
>       define some other, non-NIST-like KDFs, the interface is flexible
>       enough to handle that.  Changed "KDF" to "KDF-alg".
>    o  in 3.2, clarified that the output of the function is called "MAC
>       =", to have a similar look and feel to sect 3.1's function. also
>       changed MAC(foo) to "MAC_alg", and dropped "Output_Length" from
>       the function parameters, as it is specified as a fixed element for
>       each MAC defined, but not passed as a parameter of the function.
>    o  sect 3.2 - removed "truncation" from interface definition, and
>       placed it as a fixed element of the MAC definition. sect 3.2.1 and
>       3.2.2 - changed "truncation:" field to "Output:".  Removed text
>
>
>
>Lebovitz & Rescorla      Expires April 29, 2010                [Page 12]
>
>Internet-Draft              Crypto for TCP-AO               October 2009
>
>
>       about RFC4493 from end of 3.2.2.
>    o  sect 3.1.1.2, changed back to follow 4615 exactly (agreement with
>       polk, mcgrew, lebovitz, ekr)
>    o  sect 3.1.1.3, deleted the following: "When such a time arrives as
>       KDF_AES_128_CMAC becomes widely deployed, this document should be
>       updated so that it becomes the default KDF on implementations."
>    o  Minor text change in section 3.1 and 3.2, to the definition of
>       "Context" in both - Joe Touch
>    o  minor text change in 3.1.1 clarifying that the concatenation is of
>       binary strings - Joe Touch
>
>    draft-ietf...-00 - 4th submission
>
>    o  Submitting draft-lebovitz...-02 as a WG document.  Added EKR as
>       co- author, and gave him credit for rewrite of sect 3.1.x .
>
>    lebovitz...-02 - 3rd submission
>
>    o  cleaned up explanation in 3.1.2
>    o  in 3.1.2, changed the key extractor mechanism back, from using an
>       alphanumeric string for the fixed key C to use 0^128 as the key
>       (as it was in -00) (Polk & Ekr)
>    o  deleted cut-and-paste error text from sect 3.1 between "label" and
>       "context"
>    o  changed "conn_key" to "traffic_key" throughout, to follow auth-
>       opt-05
>    o  changed "tsad" to "mkt" throughout, to follow auth-opt-05
>    o  changed "conn_block" to "data_block" throughout, to follow auth-
>       opt-05
>
>    lebovitz...-01- 2nd submission
>
>    o  removed the whole section on labels (previously section 4), per WG
>       consensus at IETF74.  Added 3.1.3 to specify that implementations
>       SHOULD make HMAC-SHA1 the default choice for the time being, and
>       to suggest common names for the KDF's universally in UI's.
>    o  changed KDF = PRF... to Derived_Key = KDF...  (EKR)
>    o  added the text on how to deal with future KDF to end of s3.1 (EKR)
>    o  removed references to TCP-AO "manual key mode".  Changed to TCP-
>       AO's "current mode of manual keying".  (Touch)
>    o  removed the whole MUST- / SHOULD+ thing.  Both KDF's are MUST now,
>       per wg consensus at ietf74.
>    o  in 3.1.2, changed the mechanism to force the K to be 128bits from
>       using 0^128, to using a fixed 128-bit string of random characters
>       (Dave McGrew)
>    o  sect 3.1, in Input description, dropped "0x00".  Added "NOTE"
>       explaining why right after the output_length description.
>
>
>
>
>Lebovitz & Rescorla      Expires April 29, 2010                [Page 13]
>
>Internet-Draft              Crypto for TCP-AO               October 2009
>
>
>    o  cleaned up all references
>    o  copy editing
>
>    lebovitz...-00 - original submission
>
>
>5.  Needs Work in Next Draft (RFC Editor: Delete Before Publishing)
>
>    [NOTE TO RFC EDITOR: this section for use during I-D stage only.
>    Please remove before publishing as RFC.]
>
>    List of stuff that still needs work
>    o  should be ready for WG LC.  Any changes will come from final WG
>       review or IESG review.
>
>
>6.  Security Considerations
>
>    This document inherits all of the security considerations of the
>    TCP-AO, the AES-CMAC, and the HMAC-SHA-1 documents.
>
>    The security of cryptographic-based systems depends on both the
>    strength of the cryptographic algorithms chosen and the strength of
>    the keys used with those algorithms.  The security also depends on
>    the engineering of the protocol used by the system to ensure that
>    there are no non-cryptographic ways to bypass the security of the
>    overall system.
>
>    Care should also be taken to ensure that the selected key is
>    unpredictable, avoiding any keys known to be weak for the algorithm
>    in use. ][RFC4086] contains helpful information on both key
>    generation techniques and cryptographic randomness.
>
>    Note that in the composition of KDF_AES_128_CMAC, the PRF needs a 128
>    bit / 16 byte key as the seed.  However, for convenience to the
>    administrators/deployers, we did not want to force them to enter a 16
>    byte Master_Key. So we specified the sub-key routine that could
>    handle a variable length Master_Key, one that might be less than 16
>    bytes.  This does NOT mean that administrators are safe to use weak
>    keys.  Administrators are encouraged to follow [RFC4086] as listed
>    above.  We simply attempted to "put a fence around stupidity", in as
>    much as possible.
>
>    This document concerns itself with the selection of cryptographic
>    algorithms for the use of TCP-AO.  The algorithms identified in this
>    document as "MUST implement" or "SHOULD implement" are not known to
>    be broken at the current time, and cryptographic research so far
>    leads us to believe that they will likely remain secure into the
>
>
>
>Lebovitz & Rescorla      Expires April 29, 2010                [Page 14]
>
>Internet-Draft              Crypto for TCP-AO               October 2009
>
>
>    foreseeable future.  Some of the algorithms may be found in the
>    future to have properties significantly weaker than those that were
>    believed at the time this document was produced.  Expect that new
>    revisions of this document will be issued from time to time.  Be sure
>    to search for more recent versions of this document before
>    implementing.
>
>
>7.  IANA Considerations
>
>    IANA has created and will maintain a registry called, "Cryptographic
>    Algorithms for TCP-AO".  The registry consists of a text string and
>    an RFC number that lists the associated transform(s).  New entries
>    can be added to the registry only after RFC publication and approval
>    by an expert designated by the IESG.
>
>    The registry has the following initial values:
>
>
>       SHA1           [This RFC when published]
>       AES128         [This RFC when published]
>
>
>
>8.  Acknowledgements
>
>    Eric "EKR" Rescorla, who provided a ton of input and feedback,
>    including a somewhat heavy re-write of section 3.1.x, earning him and
>    author slot on the document.
>
>    Paul Hoffman, from whose [RFC4308] I sometimes copied, to quickly
>    create a first draft here.
>
>    Tim Polk, whose email summarizing SAAG's guidance to TCPM on the two
>    hash algorithms for TCP-AO is largely cut and pasted into various
>    sections of this document.
>
>    Jeff Schiller, Donald Eastlake and the IPsec WG, whose [RFC4307] &
>    [RFC4305] text was consulted and sometimes used in the Requirements
>    Section 2 section of this document.
>
>    (In other words, I was truly only an editor of others' text in
>    creating this document.)
>
>    Eric "EKR" Rescorla and Brian Weis, who brought to clarity the issues
>    with the inputs to PRFs for the KDFs.  EKR was also of great
>    assistance in how to structure the text, as well as helping to guide
>    good cryptographic decisions.
>
>
>
>Lebovitz & Rescorla      Expires April 29, 2010                [Page 15]
>
>Internet-Draft              Crypto for TCP-AO               October 2009
>
>
>    The TCPM working group, who put up with all us crypto and routing
>    folks DoS'ing their WG for 2 years, and who provided reviews of this
>    document.
>
>
>9.  References
>
>9.1.  Normative References
>
>    [I-D.ietf-tcpm-tcp-auth-opt]
>               Touch, J., Mankin, A., and R. Bonica, "The TCP
>               Authentication Option", draft-ietf-tcpm-tcp-auth-opt-05
>               (work in progress), July 2009.
>
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>9.2.  Informative References
>
>    [HMAC-ATTACK]
>               "On the Security of HMAC and NMAC Based on HAVAL, MD4,
>               MD5, SHA-0 and SHA-1"", 2006,
>               <http://eprint.iacr.org/2006/187
>               http://www.springerlink.com/content/00w4v62651001303>.
>
>    [I-D.narten-iana-considerations-rfc2434bis]
>               Narten, T. and H. Alvestrand, "Guidelines for Writing an
>               IANA Considerations Section in RFCs",
>               draft-narten-iana-considerations-rfc2434bis-09 (work in
>               progress), March 2008.
>
>    [NIST-SP800-108]
>               National Institute of Standards and Technology,
>               "Recommendation for Key Derivation Using Pseudorandom
>               Functions", SP 800-108, April 2008.
>
>    [NIST-SP800-38B]
>               National Institute of Standards and Technology,
>               "Recommendation for Block Cipher Modes of Operation: The
>               CMAC Mode for Authentication", SP 800-38B, May 2005.
>
>    [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
>               Hashing for Message Authentication", RFC 2104,
>               February 1997.
>
>    [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
>               Internet Protocol", RFC 2401, November 1998.
>
>
>
>
>Lebovitz & Rescorla      Expires April 29, 2010                [Page 16]
>
>Internet-Draft              Crypto for TCP-AO               October 2009
>
>
>    [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
>               ESP and AH", RFC 2404, November 1998.
>
>    [RFC2406]  Kent, S. and R. Atkinson, "IP Encapsulating Security
>               Payload (ESP)", RFC 2406, November 1998.
>
>    [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
>               Requirements for Security", BCP 106, RFC 4086, June 2005.
>
>    [RFC4305]  Eastlake, D., "Cryptographic Algorithm Implementation
>               Requirements for Encapsulating Security Payload (ESP) and
>               Authentication Header (AH)", RFC 4305, December 2005.
>
>    [RFC4307]  Schiller, J., "Cryptographic Algorithms for Use in the
>               Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
>               December 2005.
>
>    [RFC4308]  Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308,
>               December 2005.
>
>    [RFC4493]  Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The
>               AES-CMAC Algorithm", RFC 4493, June 2006.
>
>    [RFC4615]  Song, J., Poovendran, R., Lee, J., and T. Iwata, "The
>               Advanced Encryption Standard-Cipher-based Message
>               Authentication Code-Pseudo-Random Function-128 (AES-CMAC-
>               PRF-128) Algorithm for the Internet Key Exchange Protocol
>               (IKE)", RFC 4615, August 2006.
>
>
>Authors' Addresses
>
>    Gregory Lebovitz
>    Juniper Networks, Inc.
>    1194 North Mathilda Ave.
>    Sunnyvale, CA  94089-1206
>    US
>
>    Phone:
>    Email: [email-masked]
>
>
>
>
>
>
>
>
>
>
>
>Lebovitz & Rescorla      Expires April 29, 2010                [Page 17]
>
>Internet-Draft              Crypto for TCP-AO               October 2009
>
>
>    Eric Rescorla
>    RTFM, Inc.
>    2064 Edgewood Drive
>    Palo Alto, CA  94303
>    US
>
>    Phone: 650-678-2350
>    Email: [email-masked]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>Lebovitz & Rescorla      Expires April 29, 2010                [Page 18]
>
>
>
>+++++++++++++++++++++++
>IETF-related email from
>Gregory M. Lebovitz
>Juniper Networks
>g r e go r  y d o t  i e tf a t  g m a i l  do t c o  m