RE: ESP_NULL internet draft submitted

["Patel, Baiju V" <[e-mail]>]

Three comments:

1. Should the pad length field be present and set to 0 or omitted?
2. This will mean that the authentication data will not be at 
4 or 8 byte boundary (which is typically the case
when ESP is used with popular encryption algorithms). 
This may create a problem for some hardware
ESP accelerators!

Section suggests that we can use keys of non-zero length.

2.1 Keying Material

   Like other modern ciphers, e.g., RC5 [RFC-2040], the NULL encryption
   algorithm can make use of keys of varying lengths.  However, no
   measurable increase in security is afforded by the use of longer key
   lengths.

Section 3 requires that key length is 0. One of the two should be
changed
to avoid confusion.

3. ESP_NULL Operational Requirements

      For purposes of IKE [IKE] key extraction, the key size for this
   algorithm MUST be zero (0) bits, to facilitate interoperability and
   to avoid any potential export control problems.

Baiju

> -----Original Message-----
> From:	[e-mail] [SMTP:[e-mail]]
> Sent:	Friday, March 13, 1998 6:56 AM
> To:	[e-mail]
> Subject:	ESP_NULL internet draft submitted
> 
> 
> As some already know, it became apparent at the Raleigh
> Interoperability
> Workshop that a draft defining ESP_NULL was needed.  Steve Kent and I
> have put a draft together (draft-ietf-ipsec-ciph-null-00.txt) and it
> was submitted earlier today.  I've also included a copy below.
> 
> Steve Kent and others are aware that this will require changes to 
> the ESP draft and possibly the Architecture draft.
> 
> If for no other reason than to get a smile and a chuckle I'd highly
> recommend taking a look at this draft.
> 
> Best Regards,
> 
> Rob G.  [e-mail]
> 
> --------------cut here------------------
> 
> 
> 
> 
> 
> 
> Network Working Group                                IPsec Working
> Group
> INTERNET DRAFT                                            R. Glenn,
> NIST
> Expire in six months                                   S. Kent, BBN
> Corp
>                                                               March
> 1998
> 
> 
>           The NULL Encryption Algorithm and Its Use With IPsec
>                   <draft-ietf-ipsec-ciph-null-00.txt>
> 
> 
> 
> 
> Status of this Memo
> 
>    This document is a submission to the IETF Internet Protocol
> Security
>    (IPSEC) Working Group. Comments are solicited and should be
> addressed
>    to the working group mailing list ([e-mail]) or to the editor.
> 
>    This document is an Internet-Draft.  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 draft documents are 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."
> 
>    To learn the current status of any Internet-Draft, please check the
>    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
>    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
>    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
>    ftp.isi.edu (US West Coast).
> 
>    Distribution of this memo is unlimited.
> 
> Abstract
> 
>    This draft defines the NULL encryption algorithm and its use with
> the
>    IPsec Encapsulating Security Payload (ESP).  NULL does nothing to
>    alter plaintext data.  In fact, NULL, by itself, does nothing.
> NULL
>    provides the means for ESP to provide authentication and integrity
>    without confidentiality.
> 
>    Further information on the other components necessary for ESP
>    implementations is provided by [ESP] and [ROAD].
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Glenn,Kent                                                      [Page
> 1]
> 
> INTERNET DRAFT                 March 1998         Expires September
> 1998
> 
> 
> 1.  Introduction
> 
>    This draft defines the NULL encryption algorithm and its use with
> the
>    IPsec Encapsulating Security Payload [ESP] to provide
> authentication
>    and integrity without confidentiality.
> 
>    NULL is a block cipher the origins of which appear to be lost in
>    antiquity.  Despite rumors that the National Security Agency
>    suppressed publication of this algorithm, there is no evidence of
>    such action on their part. Rather, recent archaeological evidence
>    suggests that the NULL algorithm was developed in Roman times, as
> an
>    exportable alternative to Ceaser ciphers. However, because Roman
>    numerals lack a symbol for zero, written records of the algorithm's
>    development were lost to historians for over two millennia.
> 
>    [ESP] specifies the use of an optional encryption algorithm to
>    provide confidentiality and the use of an optional authentication
>    algorithm to provide authentication and integrity.  The NULL
>    encryption algorithm is a convenient way to represent the option of
>    not applying encryption.  This is referred to as ESP_NULL in [DOI].
> 
>    The IPsec Authentication Header [AH] specification provides a
> similar
>    service, by computing authentication data which covers the data
>    portion of a packet as well as the immutable in transit portions of
>    the IP header.  ESP_NULL does not include the IP header in
>    calculating the authentication data.  This can be useful in
> providing
>    IPsec services through Network Address Translation (NAT) devices
> and
>    non-IP network devices.   The discussion on how ESP_NULL might be
>    used with NAT and non-IP network devices is outside the scope of
> this
>    document.
> 
>    In this draft, NULL is used within the context of ESP.  For further
>    information on how the various pieces of ESP fit together to
> provide
>    security services, refer to [ESP] and [ROAD].
> 
>    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 [RFC 2119].
> 
> 2. Algorithm Definition
> 
>    NULL is defined mathematically by the use of the Identity function
> I
>    applied to a block of data b such that:
> 
>      NULL(b) = I(b) = b
> 
> 2.1 Keying Material
> 
>    Like other modern ciphers, e.g., RC5 [RFC-2040], the NULL
> encryption
>    algorithm can make use of keys of varying lengths.  However, no
>    measurable increase in security is afforded by the use of longer
> key
>    lengths.
> 
> 
> 
> 
> 
> Glenn,Kent                                                      [Page
> 2]
> 
> INTERNET DRAFT                 March 1998         Expires September
> 1998
> 
> 
> 2.2 Cryptographic Synchronization
> 
>    Because of the stateless nature of the NULL encryption algorithm,
> it
>    is not necessary to transmit an IV or similar cryptographic
>    synchronization data on a per packet (or even a per SA) basis.  The
>    NULL encryption algorithm combines many of the best features of
> both
>    block and stream ciphers, while still not requiring the
> transmission
>    of an IV or analogous cryptographic synchronization data.
> 
> 2.3 Padding
> 
>    NULL has a block size of 1 byte, thus padding is not necessary.
> 
> 2.4. Performance
> 
>    The NULL encryption algorithm is significantly faster than other
>    commonly used symmetric encryption algorithms and implementations
> of
>    the base algorithm are available for all commonly used hardware and
>    OS platforms.
> 
> 2.5 Test Vectors
> 
>    The following is a set of test vectors to facilitate in the
>    development of interoperable NULL implementations.
> 
>      test_case =      1
>      data =           0x123456789abcdef
>      data_len =       8
>      NULL_data =      0x123456789abcdef
> 
>      test_case =      2
>      data =           "Network Security People Have A Strange Sense Of
> Humor"
>      data_len =       53
>      NULL_data =      "Network Security People Have A Strange Sense Of
> Humor"
> 
> 3. ESP_NULL Operational Requirements
> 
>    ESP_NULL is defined by using NULL within the context of ESP.  This
>    section further defines ESP_NULL by pointing out particular
>    operational parameter requirements.
> 
>    For purposes of IKE [IKE] key extraction, the key size for this
>    algorithm MUST be zero (0) bits, to facilitate interoperability and
>    to avoid any potential export control problems.
> 
>    To facilitate interoperability, the IV size for this algorithm MUST
>    be zero (0) bits.
> 
>    Padding MAY be included on outgoing packets as specified in [ESP].
> 
> 4. Security Considerations
> 
>    The NULL encryption algorithm offers no confidentiality nor does it
>    offer any other security service.  It is simply a convenient way to
> 
> 
> 
> Glenn,Kent                                                      [Page
> 3]
> 
> INTERNET DRAFT                 March 1998         Expires September
> 1998
> 
> 
>    represent the optional use of applying encryption within ESP.  ESP
>    can then be used to provide authentication and integrity without
>    confidentiality.  Unlike AH these services are not applied to any
>    part of the IP header.  At the time of this writing there is no
>    evidence to support that ESP_NULL is any less secure than AH when
>    using the same authentication algorithm (i.e. a packet secured
> using
>    ESP_NULL with some authentication algorithm is as cryptographically
>    secure as a packet secured using AH with the same authentication
>    algorithm).
> 
>    As stated in [ESP], while the use of encryption algorithms and
>    authentication algorithms are optional in ESP, it is imperative
> that
>    an ESP SA specifies the use of at least one cryptographically
> strong
>    encryption algorithm or one cryptographically strong authentication
>    algorithm or one of each.
> 
>    At the time of this writing there are no known laws preventing the
>    exportation of NULL with a zero (0) bit key length.
> 
> 5.  Intellectual Property Rights
> 
>    Pursuant to the provisions of [RFC-2026], the authors represent
> that
>    they have disclosed the existence of any proprietary or
> intellectual
>    property rights in the contribution that are reasonably and
>    personally known to the authors.  The authors do not represent that
>    they personally know of all potentially pertinent proprietary and
>    intellectual property rights owned or claimed by the organizations
>    they represent or third parties.
> 
> 6.  Acknowledgments
> 
>    Steve Bellovin suggested and provided the text for the Intellectual
>    Property Rights section.
> 
>    Credit also needs to be given to the participants of the Cisco/ICSA
>    IPsec & IKE March 1998 Interoperability Workshop since it was there
>    that the need for this document became apparent.
> 
> 7.  References
> 
>    [ESP]        Kent, S., Atkinson, R., "IP Encapsulating Security
>                 Payload", draft-ietf-ipsec-esp-v2-03.txt, work in
> progress,
>                 February 1998.
> 
>    [AH]         Kent, S., Atkinson, R., "IP Authentication Header",
>                 draft-ietf-ipsec-auth-header-04.txt, work in progress,
>                 February 1998.
> 
>    [ROAD]       Thayer, R., Doraswamy, N., Glenn, R., "IP Security
>                 Document Roadmap",
>                 draft-ietf-ipsec-doc-roadmap-02.txt, work in progress,
>                 November 1997.
> 
>    [DOI]        Piper, D., "The Internet IP Security Domain of
> 
> 
> 
> Glenn,Kent                                                      [Page
> 4]
> 
> INTERNET DRAFT                 March 1998         Expires September
> 1998
> 
> 
>                 Interpretation for ISAKMP",
>                 draft-ietf-ipsec-ipsec-doi-07.txt, work in progress,
>                 February 1998.
> 
>    [IKE]        Harkins, D., Carrel, D., "The Internet Key Exchange
>                 (IKE)", draft-ietf-ipsec-isakmp-oakley-06.txt, work in
>                 progress, February 1998.
> 
>    [RFC-2026]   Bradner, S., "The Internet Standards Process --
>                 Revision 3", RFC2026, October 1996.
> 
>    [RFC-2040]   Baldwin, R.W., Rivest, R., "The RC5, RC5-CBC, RC5-CBC-
>                 Pad, and RC5-CTS Algorithms", RFC2040, October 1996
> 
>    [RFC-2119]   Bradner, S., "Key words for use in RFCs to Indicate
>                 Requirement Levels", RFC-2119, March 1997.
> 
> 
> 6.  Editors' Address
> 
>         Rob Glenn
>         NIST
>         e-mail: [e-mail]
> 
>         Stephen Kent
>         BBN Corporation
>         e-mail: [e-mail]
> 
>    The IPsec working group can be contacted through the chairs:
> 
>         Robert Moskowitz
>         ICSA
>         e-mail: [e-mail]
> 
>         Ted T'so
>         Massachusetts Institute of Technology
>         e-mail: [e-mail]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Glenn,Kent                                                      [Page
> 5]
> 
> 
>