[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
ipdvb Working Group                                 Michael Noisternig
                                               Bernhard Collini-Nocker
Internet Draft                                  University of Salzburg
                                                         July 14, 2008
Expires: January 2009



                 A lightweight security extension for the
          Unidirectional Lightweight Encapsulation (ULE) protocol
                     draft-noisternig-ipdvb-ulesec-01


Status of this Document

   By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, in accordance with Section 6 of
   BCP 79.

   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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on January 14, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   The Unidirectional Lightweight Encapsulation (ULE) protocol is an
   efficient and extensible transport mechanism for IP over MPEG-2
   networks. Such networks are often operated on broadcast wireless



Noisternig            Expires January 14, 2009                [Page 1]


Internet-Draft A lightweight security extension for ULE       July 2008


   channels, and are thus specifically vulnerable to attacks. Passive
   attacks, such as eaves-dropping, are simple to perform and emphasize
   the importance of security support within ULE.

   This document defines a mandatory security extension for the ULE
   protocol that is designed with the aim of being conservative in
   bandwidth consumption and lightweight in the sense that it allows for
   implementation in low-cost, resource-scarce (mobile) receiver
   devices. The extension may be easily adapted to the Generic Stream
   Encapsulation (GSE) protocol, which uses the same extension header
   mechanism. The document describes the format of the security
   extension header, specifies default security algorithms to be used
   with this extension, and gives detailed processing descriptions for
   devices implementing the security extension.

Conventions used in this document

   The following DVB specific terms are taken from [RFC4326] and
   recapitulated here for easy lookup:

   DVB: Digital Video Broadcast.  A framework and set of associated
   standards published by the European Telecommunications Standards
   Institute (ETSI) for the transmission of video, audio, and data using
   the ISO MPEG-2 standard [MPEG2].

   MPEG-2: A set of standards specified by the Motion Picture Experts
   Group (MPEG) and standardized by the International Standards
   Organization (ISO/IEC 13818-1) [MPEG2] and ITU-T [H222].

   NPA: Network Point of Attachment.  In this document, refers to a 48-
   bit destination address (resembling an IEEE MAC address) within the
   MPEG-2 transmission network that is used to identify individual
   receivers or groups of receivers.

   PDU: Protocol Data Unit.  Examples of a PDU include Ethernet frames,
   IPv4 or IPv6 datagrams, and other network packets.

   PID: Packet Identifier [MPEG2].  A 13-bit field carried in the header
   of TS cells.  This is used to identify the TS Logical Channel to
   which a TS cell belongs [MPEG2].

   SNDU: SubNetwork Data Unit.  An encapsulated PDU sent as an MPEG-2
   payload unit.

   TS: Transport Stream [MPEG2].  A method of transmission at the MPEG-2
   level using TS cells; it represents layer 2 of the ISO/OSI reference
   model.


Noisternig            Expires January 14, 2009                [Page 2]


Internet-Draft A lightweight security extension for ULE       July 2008


   TS Logical Channel: Transport Stream Logical Channel.  In this
   document, this term identifies a channel at the MPEG-2 level [MPEG2].
   All packets sent over a TS Logical Channel carry the same PID value.

   ULE: Unidirectional Lightweight Encapsulation [RFC4326].  A protocol
   that encapsulates PDUs into SNDUs that are sent in a series of TS
   cells using a single TS Logical Channel.

   Terms and abbreviations from cryptography are explained when they
   first appear within this document.

   All numbers encoded in protocols are to be interpreted in network
   byte order.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", when
   appearing within this document, are to be interpreted as described in
   [RFC2119].

Table of Contents

   1. Introduction ................................................. 4
   2. Format of the ULE Security Extension Header .................. 6
      2.1. Type field .............................................. 7
      2.2. VPN-ID field ............................................ 7
      2.3. Key (K) bit ............................................. 7
      2.4. Sequence Number.......................................... 8
      2.5. Encrypted Destination Address field ..................... 8
      2.6. PDU Type field .......................................... 8
      2.7. MAC field ............................................... 8
   3. Security Algorithms .......................................... 8
      3.1. Key Derivation .......................................... 9
      3.2. Encryption .............................................. 9
      3.3. Identity Protection .................................... 10
      3.4. Authentication and Integrity Protection ................ 11
      3.5. Replay Protection ...................................... 12
   4. Security Extension Header Processing ........................ 12
      4.1. Preliminaries .......................................... 12
         4.1.1. Security Policy Database (SPD) .................... 13
         4.1.2. Security Association Database (SAD) ............... 14
      4.2. Sender Processing ...................................... 16
         4.2.1. General Activity Diagram .......................... 16
         4.2.2. Detailed Processing Description ................... 16
      4.3. Receiver Processing .................................... 20
         4.3.1. General Activity Diagram .......................... 20
         4.3.2. Detailed Processing Description ................... 21
   5. Key Management Considerations ............................... 23


Noisternig            Expires January 14, 2009                [Page 3]


Internet-Draft A lightweight security extension for ULE       July 2008


      5.1. Unidirectional Key Management .......................... 24
      5.2. Bidirectional Key Management ........................... 25
   6. Security Considerations ..................................... 25
   7. IANA Considerations ......................................... 26
   8. Conclusions ................................................. 26
   9. Acknowledgments ............................................. 27
   APPENDIX A: Rationale for the Extension Header Format .......... 28
      A.1. (16-bit) optional VPN-ID vs. (32-bit) SPI .............. 28
      A.2. VPN-ID + K-Bit vs. SPI ................................. 28
      A.3. 31-bit/63-bit Sequence Number .......................... 29
      A.4. MAC field .............................................. 29
   APPENDIX B: Rationale for the Default Security Algorithms ...... 30
      B.1. Encryption ............................................. 30
      B.2. Identity protection .................................... 31
      B.3. Authentication ......................................... 32
      B.4. Source Authentication .................................. 33
      B.5. Combined Authentication and Encryption ................. 34
      B.6. Replay Protection ...................................... 35
   10. References ................................................. 36
      10.1. Normative References .................................. 36
      10.2. Informative References ................................ 36
   Author's Addresses ............................................. 41
   Intellectual Property Statement ................................ 41
   Disclaimer of Validity ......................................... 42


1. Introduction

   The Unidirectional Lightweight Encapsulation (ULE) protocol [RFC4326]
   has been designed as an efficient and extensible encapsulation
   mechanism of IPv4/IPv6 and other network layer packets over the ISO
   MPEG-2 Transport Stream (TS) [MPEG2]. It has a simple base format,
   but as such does not offer any security services; however, MPEG-2
   networks are often operated on wireless channels, such as satellite
   DVB-S [DVB-S] and terrestrial wireless DVB-T [DVB-T] and DVB-H [DVB-
   H] links, and are thus specifically vulnerable to attacks [ULEsec-
   Req]. Passive attacks, such as eavesdropping packet data or
   monitoring the identities (addresses) of the communicating parties,
   are easy to perform, and remain undetected. Low cost receiver devices
   and the large coverage area of satellite senders add to the
   likelihood of such events. Effective means to secure the ULE link are
   therefore important.

   One solution is to rely on end-to-end security, and on one hand,
   reliable security can only be end-to-end. On the other hand, end-to-
   end security may not be applicable: this is because both sides of a
   communication must provide support for the same security mechanism,


Noisternig            Expires January 14, 2009                [Page 4]


Internet-Draft A lightweight security extension for ULE       July 2008


   which will not be realizable under many conditions where the two
   sides are not under central control (e.g., when browsing a public web
   site). One important security requirement cannot be attained by end-
   to-end security at all: the protection of the end-point addresses
   ("identities") of the communicating parties against eavesdropping
   (subsequently referred to as "identity protection").

   By securing the ULE link only, solutions can be provided for these
   problems. In addition, this has the benefit that the ULE broadcast
   link becomes transparent for the user in the sense that he or she can
   rely on security assumptions as of wired links [RFC3819]. The IPsec
   [RFC4301] security protocols could be used in tunnel mode to create
   such a secure link, but this will result in significant bandwidth
   overhead on satellite links (due to the IP-in-IP encapsulation).
   Current IPsec specifications only define pairwise tunnels between two
   devices, thus this option is not applicable for multicast and
   broadcast transmissions. Last but not least, the rather high
   complexity of IPsec implementations might make its realization within
   low-cost receiver devices difficult.

   Implementing security at the ULE link layer addresses above problems.
   A more detailed rationale for ULE link layer security and a
   comparison of security at the various layers can be found in [ULEsec-
   Req]. It also lists the security requirements for the ULE link.

   This document defines a mandatory security extension for the ULE
   protocol that is designed with the aim of being conservative in
   bandwidth consumption and lightweight in the sense that it allows for
   implementation in low-cost, resource-scarce (mobile) receiver
   devices. The extension may be easily adapted to the second-generation
   Generic Stream Encapsulation (GSE) protocol [GSE], which shares the
   extension header mechanism with ULE. The format of the security
   extension header is described in section 2, and default security
   algorithms to be used with this extension are specified in section 3.
   These algorithms should address the most important security
   requirements for the ULE link: data confidentiality, identity
   protection, integrity protection, data authentication, and replay
   protection. Section 4 then gives detailed processing descriptions for
   devices implementing the security extension. While not defining any
   protocol for automated key management, some guidelines are given in
   section 5. After security and IANA considerations in sections 6 and
   7, conclusions are presented in section 8. At the end of this
   document, two appendices support the reader with more insight and
   rationale on the decisions taken within this specification.





Noisternig            Expires January 14, 2009                [Page 5]


Internet-Draft A lightweight security extension for ULE       July 2008


2. Format of the ULE Security Extension Header

   This section defines the format of the ULE security extension header,
   ULEsec header in short. This format can be regarded as a framework
   for a set of security transforms. While section 3 defines default
   algorithms to be used within that framework, other security
   transforms, especially making use of other cryptographic primitives,
   modes, and key lengths, may be devised later and defined within
   separate documents.

   Figure 1 below shows an example format of a ULE SubNetwork Data Unit
   (SNDU) containing a ULEsec header. In this example, the ULEsec
   extension header directly follows the base header, and it is
   RECOMMENDED that encapsulation devices always be configured that way.
   Users not following this recommendation must clearly understand the
   implications: first, extension headers preceding the ULEsec header
   cannot be protected under the data confidentiality service; second,
   when processing the security extension header, a receiver device may
   decide to discard the SNDU, a point at which preceding headers will
   already have been evaluated.

    0                               16                           31
   +-+-----------------------------+------------------------------+
   |D|           Length            |    Type=ULEsec/ULEsec_ID     |
   +-+-----------------------------+------------------------------+
   |                   Destination Address (D=0)                  |
   |                               +------------------------------+
   |                               |   VPN-ID (Type=ULEsec_ID)    |
   +-+-----------------------------+------------------------------+
   |K|                Sequence Number (31/63 bits)                |
   +-+-----------------------------+------------------------------+
   |           Encrypted Destination Address (optional)           |
   |                               +------------------------------+
   |                               |     (Encrypted) PDU Type     |
   +-------------------------------+------------------------------+
   |                                                              |
   ~                   (Encrypted) Payload Data                   ~
   |                                                              |
   |                                                              |
   +--------------------------------------------------------------+
   |                                                              |
   ~                        MAC (optional)                        ~
   |                                                              |
   +--------------------------------------------------------------+
   |                            CRC-32                            |
   +--------------------------------------------------------------+
      Figure 1 Example ULE SNDU containing a security extension header


Noisternig            Expires January 14, 2009                [Page 6]


Internet-Draft A lightweight security extension for ULE       July 2008



   The following subsections describe the fields that are part of or
   directly relevant to the ULEsec header. All encoded numbers are in
   network byte order.

2.1. Type field

   The 16-bit Type field of the ULE base header (or some other extension
   header) indicates a security extension header following subsequently.
   Two different type values are defined. The first one, denoted simply
   ULEsec, SHOULD be used when receiver devices can uniquely identify
   Security Associations (SAs) based on MPEG-2 TS Program Identifiers
   (PIDs) and SNDU destination addresses solely. The second type,
   denoted ULEsec_ID, MUST be used, when PIDs and destination addresses
   alone are not sufficient to look up SAs. In this case, the VPN-ID
   field will be present, which is described next.

2.2. VPN-ID field

   This 16-bit field is present when the ULEsec_ID Type is chosen. It
   can be viewed as a Security Parameter Index (SPI) as of IPsec
   implementations [RFC4301], but more adequately simply represents a
   Virtual Private Network (VPN) identifier. See above to decide when to
   use this field.

2.3. Key (K) bit

   This mandatory bit provides for an easy way of detecting a key
   update. Whenever ULE sender (i.e., ULE encapsulator) devices switch
   to new keys, they flip this bit. This enables receivers to find out
   which of two concurrently defined set of keys (the current/old ones,
   or the new ones) are to be used for decoding.

   New keys will be issued within key management messages by a Group
   Controller and Key Server (GCKS), which may or may not physically
   reside with a ULE sender. After each key update, devices MUST wait
   for a policy-defined amount of time before they permit switching to
   new keys again. This is necessary to avoid collisions between
   different keys on SNDUs sent with the same K bit. This can happen
   either because a receiver still accepts old keys (see section 4.3),
   or because a device has missed all key management messages during two
   periods of key updates. To avoid the latter, a GCKS may periodically
   send out key management messages with the key currently in use (see
   section 5.1).





Noisternig            Expires January 14, 2009                [Page 7]


Internet-Draft A lightweight security extension for ULE       July 2008


2.4. Sequence Number

   The mandatory Sequence Number field serves two purposes. First, it is
   part of the nonce required for the default encryption algorithm.
   Second, it is used for the replay protection service.

   The default size of the Sequence Number field is 31 bits. This MAY be
   extended to 63 bits when configured as such by a Security Policy (SP)
   or via negotiation within a key management protocol. The larger size
   MUST be used when no automated key management is available.

2.5. Encrypted Destination Address field

   This field is only present if the identity protection service is used
   (determined by the SPs selected). In that case, SNDUs do not contain
   a 48-bit NPA destination address in the ULE base header (i.e., they
   have the D bit set to 1), but the address will appear in the security
   extension header's Encrypted Destination Address field instead, where
   it will be encrypted subsequently (along with the payload data).

2.6. PDU Type field

   This mandatory 16-bit field designates the type of the PDU or the
   next extension header in the header chain.

2.7. MAC field

   The security extension header has an optional (SP-configured) trailer
   that follows the PDU data and contains the Message Authentication
   Code (MAC) of the SNDU. This MAC SHOULD have a default length of 12
   octets.

3. Security Algorithms

   This section specifies a set of mandatory default security algorithms
   to be used in conjunction with the ULEsec header. These algorithms
   are lightweight in the sense that the only cryptographic primitive
   required is the Advanced Encryption Standard (AES) [AES] with a key
   size of 128 bits, denoted AES-128 in short, and only its encryption
   part is used.

   Implementation of default security algorithms is REQUIRED.

   Within the following subsections, AES_mk(value) means AES-128
   encryption of the 128-bit value using the master key mk, value[x..y]
   means taking value's bits x to y, || denotes concatenation, and x^y



Noisternig            Expires January 14, 2009                [Page 8]


Internet-Draft A lightweight security extension for ULE       July 2008


   means that bit x is to be repeated y times. All encoded numbers are
   in network byte order.

3.1. Key Derivation

   In order to minimize transmission overhead within a key management
   protocol and to ease the setup of manual keys, separate encryption
   and authentication keys are derived from a single master key. The
   derived keys are computed as follows:

   encr_key = AES_mk ( Salt || 0^64 )

   auth_key = AES_mk ( Salt || 0^63 || 1 )

   The Salt is a 64-bit value that MUST be an unpredictable value for
   adversaries. It will be transmitted along with the master key either
   explicitly or implicitly (e.g., derived from nonces used within the
   key management protocol). Including the Salt in the key derivation
   process preserves full security of the master key in case of
   compromise of any derived key against an adversary using pre-
   computation techniques.

3.2. Encryption

   Using encryption spoils an adversary's attempt of finding out
   information transmitted via eavesdropping. By encoding all data
   following a security extension header's Sequence Number field up to
   but not including the MAC field, confidentiality is provided for
   SNDUs' payload data as well as any extension headers succeeding a
   security header.

   Encryption is performed by employing AES-128 in the Counter (CTR)
   mode of operation, which is specified in [Modes], and using the
   encr_key defined in subsection 3.1.

   The CTR mode requires a Nonce as part of its input. It is a 128-bit
   value and derived per packet from a 64-bit random value (Salt) that
   is distributed along with the master key, the 13-bit Program
   Identifier (PID) the underlying MPEG-2 TS cell originated from, and
   the ULEsec header's K bit and Sequence Number as follows:

   Nonce = Salt || K || Sequence Number || 0^3 || PID || 0^16.

   When 63-bit sequence numbers are used, the Nonce is computed as such:

   Nonce = Salt[63..32] || Salt[31] XOR K || Salt[30..0] XOR Sequence
   Number[62..32] || Sequence Number[31..0] || 0^3 || PID || 0^16.


Noisternig            Expires January 14, 2009                [Page 9]


Internet-Draft A lightweight security extension for ULE       July 2008


   The Salt is the same as that of subsection 3.1, which primarily means
   that it be an unpredictable value for adversaries. Again, its purpose
   is to thwart pre-computation attacks.

   Special care has to be taken when PID re-mapping can occur (typically
   within a multiplexer on a DVB network boundary [MPEG2]), as a
   receiver will not be able to decrypt the data successfully when using
   a PID value different from the sender. For one-sender scenarios where
   the sender also acts as the key server, a simple solution to inform
   receivers about such PID re-mapping may be to include the originating
   PID within the key management messages.

3.3. Identity Protection

   For additional protection against traffic flow analysis, the ULE link
   layer addresses may be hidden using the identity protection service.
   For this, a sender omits the 48-bit NPA destination address from the
   ULE base header, sets the D bit, and places the address into the
   extension header's Encrypted Destination Address field instead, where
   it will be encrypted subsequently (along with the payload data). A
   receiver will detect an SNDU destined to it simply by probing (i.e.,
   trial-decryption).

   Identity protection has the following properties:

   o There is no need to store or transmit any additional information
      (besides that the identity protection service is requested).
      Particularly, there is no need for a central server to manage or
      distribute addresses used specifically for this service.

   o An adversary not in the know of a matching encryption key will not
      be able to read an SNDU's NPA destination address.

   o A legitimate receiver will correctly decode the address with very
      high probability. In detail, the probability that an SNDU is
      mistakenly accepted is given approximately by k*10^-14.4, where k
      is the receiver's number of keys that do not match. Note that this
      is close to typical packet-error ratios on the ULE link for small
      k, which is between 10^-15.5 and 10^-16.8 on a quasi-error-free
      channel.

   o For even lower false-acceptance rates, the authentication
      mechanism may be used. A MAC of size t bits will decrease the
      probability of erroneously accepting a SNDU with a wrong key by
      the factor 2^-t.




Noisternig            Expires January 14, 2009               [Page 10]


Internet-Draft A lightweight security extension for ULE       July 2008


   Two typical use cases for this service are sketched. In the first
   one, each receiver device has one distinct key to protect its unicast
   data. In this case, a receiver will not miss any data destined to it,
   and will mistakenly accept other SNDUs with negligible probability
   (k=1).

   In the second case, all sender and receiver devices on a PID use a
   single shared key to protect their data, forming a VPN. Within such
   VPN, all devices can correctly decode all addresses (k=0).

   Note that while identity protection could be used for unicast as well
   as multicast settings, it is sensible only for unicast communication,
   and as such - and in order to keep the number of mismatching keys low
   - should not be used for multicast scenarios.

   Identity Protection MUST NOT be used without the data confidentiality
   service (section 3.2).

3.4. Authentication and Integrity Protection

   As a mechanism against active attacks, SNDUs may carry a Message
   Authentication Code (MAC). A MAC provides integrity protection and
   source authentication for unicast connections as well as other
   single-sender settings. When there is more than one sender, such as
   in peer-to-peer settings, or when there is a possibility that a
   receiver in the know of the shared key might act as a sender, this
   mechanism gets reduced to group authentication. This is regarded
   sufficient, however, as attacks are primarily expected from outside
   (i.e., from adversaries not in the know of the right keys) [ULEsec-
   Req].

   This construction of the MAC is based on the Cipher Block Chaining
   (CBC) mode of operation [Modes], and is commonly known as a (plain)
   CBC-MAC, which is computed as follows:

   1. The SNDU, excluding the CRC and the MAC field, is first internally
      right-padded with zeros to an integral multiple of the cipher's
      block length (128 bits for AES), if necessary.

   2. This padded data is then internally encrypted with AES-128 in CBC
      mode using the auth_key defined in subsection 3.1, and an
      Initialization Vector (IV) of 0.

   3. The final output block of the encryption step resembles the full-
      length MAC whose least-significant bits are then truncated to
      receive the MAC of desired length.



Noisternig            Expires January 14, 2009               [Page 11]


Internet-Draft A lightweight security extension for ULE       July 2008


   The CBC-MAC based on AES is fully secure up to 98 bits, or about 12
   octets, when used with the default sequence number space of 2^31. 12
   octets is the "standard" authentication length for the IPsec
   protocols, and should be used as a default for ULEsec, too.

   When extended (63-bit) sequence numbers are used, a block cipher with
   larger block size should be chosen. It is advised to take the
   Rijndael algorithm [Rijndael] with a block size of 256 bits as a
   superset of AES.

3.5. Replay Protection

   Upon switching to a new set of keys, senders and receivers will set
   its sequence numbers to be sent or accepted next for a Security
   Association (SA) to the value 0. A sender will increment a sender-
   side sequence number by 1 after each SNDU transmitted, independently
   of whether replay protection is used or not. A receiver, using replay
   protection, will only accept SNDUs with a receiver-side sequence
   number higher than the last one accepted. Detailed processing
   descriptions regarding this service are given in section 4.

   Note that replay protection using sequence numbers only works for the
   one-sender scenario due to the difficulty of synchronizing replay
   state among multiple senders. As such, this service MUST NOT be used
   when there is multiple legitimate senders or legitimate receivers
   acting as senders for a SA. Also, it SHOULD NOT be used when keys are
   set up manually, as a sender would have to remember its sequence
   number state across reboots.

4. Security Extension Header Processing

4.1. Preliminaries

   Within the next subsections, the following terms are used to simplify
   wording:

   o Basic (Policy) Selector: a pair of destination NPA address and PID
      value.

   o Receiver-Side (Policy) Selector: a Basic (Policy) Selector with
      the optional VPN-ID value.

   o Sender-Side (Policy) Selector: a Basic (Policy) Selector,
      optionally extended by higher-layer selector data, such as IP
      addresses, TCP ports, etc.

   The term (Policy) Selector is used interchangeably for those above.


Noisternig            Expires January 14, 2009               [Page 12]


Internet-Draft A lightweight security extension for ULE       July 2008


4.1.1. Security Policy Database (SPD)

   Senders and receivers define policies describing the security
   services required or permitted for outgoing and incoming data. The
   collection of such Security Policies (SPs) is referred to as the
   Security Policy Database (SPD).

   For both outgoing and incoming data, a SPD contains an ordered list
   of SPs. Each SP MUST contain the following information:

   o A set of Sender-Side or Receiver-Side Policy Selectors (for
      outgoing or incoming data respectively), defining the
      applicability of this SP. To simplify parsing, this set MUST be
      encoded as a single Selector together with a Selector Mask.

   o Information about the SA(s) to be instantiated by this SP. This
      contains:

      o A set of subsets of above Policy Selectors, downgraded to Basic
         Policy Selectors (i.e., only the address and PID are taken).
         Each subset together with the optional VPN-ID value constitutes
         a SA Selector, which is used for looking up or creating a
         Security Association (SA) within the Security Association
         Database (SAD) (see next section 4.1.2). To simplify parsing, a
         single Basic Selector Mask MUST be stored, denoted SA Selector
         Mask, from which the set of subsets is derived.

      o An optional VPN-ID value, part of the SA Selector. If defined,
         a sender MUST use this value within the VPN-ID field of the
         ULEsec_ID extension header type.

      o Optional Group Controller and Key Server (GCKS) data, specified
         by an optional destination address and a (possibly empty set
         of) PID(s). A device MAY use the PID(s) as a first check for
         legitimacy of key management messages from a certain source.
         When a destination address is defined, it MUST be used to
         contact the GCKS for membership request on receiving a
         protected SNDU for which this SP matches, and when the SP does
         not contain default key data in its first set of Security
         Parameters.








Noisternig            Expires January 14, 2009               [Page 13]


Internet-Draft A lightweight security extension for ULE       July 2008


      o An ordered list of Security Parameter sets used for
         instantiating a SA, sorted according to preference. A Security
         Parameter set MUST allow having no security services selected
         at all, which MUST be interpreted as sending or receiving data
         without protection (i.e., SNDUs without a security extension
         header). A sender MUST default to the first entry in the list,
         unless a key management protocol permits negotiation (e.g., for
         unicast, bidirectional settings) and a receiver contacts the
         GCKS to request another set of Security Parameters from the
         list. Each set of Security Parameters MUST contain information
         about:

         o The cryptographic algorithms used.

         o The cryptographic parameters required by these algorithms
            (e.g., the MAC length).

         o The length of the sequence number field.

         o Optional key data for manual keying: a master key, and an
            optional Salt.

   SPs may be manually set up by the owner of the sender or receiver
   equipment, or dynamically distributed via a GCKS (using a key
   management protocol). While the resulting SPD may become complex by
   containing separate SPs for each pair of PID and NPA address data may
   be sent to or received from, in general it is expected to contain
   just a few entries.

   This document does not define how to store, manage, and look up SPs
   within the SPD, as this is regarded implementation specific details.

4.1.2. Security Association Database (SAD)

   A Security Association (SA) is an instantiation of a SP. It describes
   the current state of a secure connection between two or more devices.
   All devices sharing a SA are part of the same VPN. The set of SAs of
   a device is aggregated in the Security Association Database (SAD).

   A SA MUST contain the following information:

   o The SA Selector derived from the instantiating SP.

   o Any GCKS data defined by the SP and the GCKS.

   o Static security parameters defined by the SP (cryptographic
      algorithms, MAC length, Sequence Number length, etc.).


Noisternig            Expires January 14, 2009               [Page 14]


Internet-Draft A lightweight security extension for ULE       July 2008


   o Current and prospective dynamic security parameters (keys, Salt,
      etc.), defined by the SP or the GCKS.

   o The current sender-side K bit and sequence number for transmitting
      data.

   o The current receiver-side K bit for receiving data, and the
      current receiver-side sequence number for receiving data with
      replay protection.

   o A flag defining whether prospective security parameters have been
      received through a GCKS.

   As with the SPD, this document does not define how to store, manage,
   and look up SAs within the SAD.

































Noisternig            Expires January 14, 2009               [Page 15]


Internet-Draft A lightweight security extension for ULE       July 2008


4.2. Sender Processing

4.2.1. General Activity Diagram

         +-----------------+
         |   receive PDU   |                    +-----------------+
   +---->|from upper layers|<-------------------|   discard PDU   |
   |     +-----------------+                    +-----------------+
   |              v                                      ^
   |     +-----------------+ not found?         +-----------------+
   |     |     get SP      |------------------->|    log event    |<-+
   |     +-----------------+                    +-----------------+  |
   |              v                                      ^ failure?  |
   |     +-----------------+ not found?         +-----------------+  |
   |  +--|     get SA      |------------------->|    create SA    |  |
   |  |  +-----------------+                    +-----------------+  |
   |  |w/o        |                                      | success?  |
   |  |sec.ext.   |                     +----------------+           |
   |  |           v                     |                            |
   |  |  +-----------------+ fresh key  |       +-----------------+  |
   |  |  |   check keys    |------------------->|   switch keys   |  |
   |  |  +-----------------+ available? |       +-----------------+  |
   |  |           |                     |                |           |
   |  |           v                     |   +------------+           |
   |  |  +-----------------+ seq.nr.    |   |                        |
   |  |  |  check seq.nr.  |-----------------------------+-----------+
   |  |  +-----------------+ overflow?  |   |            v
   |  |           | expected            |   |   +-----------------+
   |  |           +---------------------------->|get key from GCKS|
   |  |           | seq.nr. overflow?   |   |   +-----------------+
   |  |           v                     |   |            v failure?
   |  |  +-----------------+            |   |   +-----------------+
   |  +->| construct SNDU  |<-----------+   |   |    log event    |
   |     |   & transmit    |<---------------+   +-----------------+
   |     +-----------------+
   |              v
   |     +-----------------+
   |     |    update SA    |
   |     +-----------------+
   |              |
   +--------------+

4.2.2. Detailed Processing Description

   The following list describes the processing steps for a ULE
   encapsulator implementing the ULE security extension (ULEsec sender
   in short):


Noisternig            Expires January 14, 2009               [Page 16]


Internet-Draft A lightweight security extension for ULE       July 2008


   1. Get SP: After receiving a PDU from upper layers for transmission
      over the ULE link, a ULEsec sender MUST consult its SPD by
      scanning the ordered list of outgoing SPs until it finds a
      matching policy. That is, it looks for a SP for which

      (SP's Sender-Side Selector AND SP's Selector Mask)
      == (SNDU's Sender-Side Selector AND SP's Selector Mask)

      is true. If no such policy can be found, the data MUST be
      discarded, and this event SHOULD be logged as an invalid
      transmission attempt.

   2. Get SA: With a SP chosen, a SA Selector is constructed as a
      triple:

      SA Selector := (SNDU's Basic Selector AND SP's SA Selector Mask,
      SP's SA Selector Mask, SP's VPN-ID value)

      The VPN-ID value, if not defined by the SP, must be set to a
      reserved "null" value (i.e., a fixed value not within the 16-bit
      number range of the extension header's VPN-ID field).

      The SA Selector is then used to look up a SA within the SAD. If no
      SA is found, it must be set up as follows: If the SP's first
      Security Parameter set either contains default key data (master
      key, optional Salt, etc.) or defines data to be sent without
      protection, the SA is immediately created and initialized
      according to these settings. Otherwise, if the SP defines a GCKS
      destination address, the server MUST be contacted for obtaining
      key material. During that attempt the sender SHOULD postpone or
      discard transmission of the data. Any case of failure MUST result
      in the data being discarded, and this SHOULD be logged accordingly
      (e.g., as a user authentication failure in case of membership
      denial by the GCKS).

   3. Check keys: Whenever a SA is provided with fresh key material, a
      sender MUST switch to the new set of keys after a policy-defined
      length or point of time, and prior to a sequence number overflow
      (see next step). This is done by flipping the SA's sender-side K
      bit and resetting the sender-side sequence number to 0, while
      selecting the fresh key material as the new current one for
      sending. Note that a SA that is also used for receiving SNDUs may
      still require the older set of keys as a receiver-side K bit will
      be flipped at a later (policy-defined) point of time. This is to
      compensate differences in key update times of multiple senders,
      which means there will be a period during which some devices will



Noisternig            Expires January 14, 2009               [Page 17]


Internet-Draft A lightweight security extension for ULE       July 2008


      already send with new keys while others will still use the old
      ones.

   4. Check sequence number: An implementation MUST NOT allow a SA's
      sender-side sequence number to overflow. For a SA defining a GCKS
      destination address, an implementation MUST contact the server for
      obtaining fresh key material in anticipation of this event. When
      keys are set up manually, the user SHOULD be warned about an
      expected overflow. Should eventual transmission of an SNDU ever
      result in the sequence number to overflow, the data MUST be
      discarded instead, and this event SHOULD be logged as a sequence
      number overflow event.

   5. Construct SNDU: For a SA that allows passing data unprotected, the
      SNDU is constructed as usual. Otherwise, it is built as follows:

        a.               First, the ULE base header and any extension headers preceding
          the security extension header are written. If the SA requests
          identity protection, the destination NPA address MUST be
          omitted from the base header (with the D bit set to 1). If a
          VPN-ID value is defined within the SA, the last extension
          header's (or base header's) Type field MUST contain the value
          for a ULEsec_ID extension header; otherwise, it contains the
          ULEsec extension header value.

        b.               For the ULEsec_ID extension header, the 16-bit VPN-ID field is
          written.

        c.               Next, the SA's sender-side K bit and sequence number are
          filled into the extension header's mandatory K Bit and
          Sequence Number fields. The length of the Sequence Number
          field is defined by the SA.

        d.               For the identity protection service, the destination NPA is
          encoded as defined by the SA, which means it will be encrypted
          along with any subsequent extension headers and the payload
          data for the default identity protection algorithm.

        e.               Subsequently, the mandatory (Encrypted) Type field, any other
          extension headers, and the PDU are encoded as defined by the
          encryption algorithm selected.

        f.               For authentication, a MAC of length as defined by the SA is
          appended. The MAC is computed over all the data encoded so
          far, which means, from the start of the SNDU to the end of the
          payload data.



Noisternig            Expires January 14, 2009               [Page 18]


Internet-Draft A lightweight security extension for ULE       July 2008


        g.               Finally, the CRC is calculated and appended, and the SNDU
          further processed according to [RFC4326].

   6. Update SA: After processing a protected SNDU is completed, a
      sender MUST increment the SA's sender-side sequence number by 1.











































Noisternig            Expires January 14, 2009               [Page 19]


Internet-Draft A lightweight security extension for ULE       July 2008


4.3. Receiver Processing

4.3.1. General Activity Diagram

         +-----------------+
         |  receive SNDU   |                    +-----------------+
   +---->| from MPEG layer |<-------------------|  discard SNDU   |
   |     +-----------------+                    +-----------------+
   |              v                                      ^
   |     +-----------------+ decoding                    |
   |     |decode headers up| error?             +-----------------+
   |     |to security ext. |------------------->|    log event    |<-+
   |     +-----------------+                    +-----------------+  |
   |              |                                ^  ^  ^  ^        |
   |              |  +-----------------------------+  |  |  |        |
   |              v  | not found/not permitted?       |  |  |        |
   |     +-----------------+                          |  |  |        |
   |  +--|     get SP      |<----------------------+  |  |  +-----+  |
   |  |  +-----------------+             no match? |  |  |        |  |
   |  |permit. |permitted        (SNDU w/o address)|  |  |        |  |
   |  |w/o     |w/                                 |  |  |        |  |
   |  |sec.    |sec. +-----------------------------|--+  |        |  |
   |  |ext.    |ext. | id.prot. mismatch?          |     |        |  |
   |  |        v     | (SNDU w/ address)           |     |failure?|  |
   |  |  +-----------------+                 +-----------------+  |  |
   |  |  |    get SA(s)    |---------------->|    create SA    |  |  |
   |  |  +-----------------+ not found?      +-----------------+  |  |
   |  |           |                                   | success?  |  |
   |  |           |  +--------------------------------+           |  |
   |  |           v  v                                            |  |
   |  |  +-----------------+ not found? +-----------------+       |  |
   |  |  |   select key    |----------->|get key from GCKS|-------+  |
   |  |  +-----------------+            +-----------------+ failure? |
   |  |           |                              |success?           |
   |  |           |  +---------------------------+                   |
   |  |           v  v                                               |
   |  |  +-----------------+                                         |
   |  +->|   decode SNDU   | decoding/authentication/replay error?   |
   |     |  & pass to L3   |-----------------------------------------+
   |     +-----------------+
   |              v
   |     +-----------------+
   |     |    update SA    |
   |     +-----------------+
   |              |
   +--------------+



Noisternig            Expires January 14, 2009               [Page 20]


Internet-Draft A lightweight security extension for ULE       July 2008


4.3.2. Detailed Processing Description

   A receiver implementing the ULE security extension (ULEsec receiver
   in short) must follow below procedure upon reception of a ULE SNDU:

   1. Decode SNDU (1): The SNDU is checked for a correct CRC as
      described in [RFC4326], after which the base header and the
      extension headers up to either a security extension header or the
      PDU are evaluated. From the base header, a Basic Policy Selector
      is constructed. This one is extended to a Receiver-Side Policy
      Selector by adding the VPN-ID field of a ULEsec_ID Type security
      extension header, when encountered.

   2. Get SP: After the SNDU passed the first filtering and evaluation
      step, the SPD's ordered list of incoming policies is scanned for a
      matching policy.

        a.               D=0: With the SNDU's D bit cleared, the following check must
          be true for selecting a SP:

          (SP's Receiver-Side Selector AND SP's Selector Mask)
          == (SNDU's Receiver-Side Selector AND SP's Selector Mask).

          If no matching policy can be found, the data MUST be discarded
          immediately, and this event SHOULD be logged as reception of
          an invalid SNDU.

        b.               D=1: When the D bit is set, above check is done as well,
          except that the destination NPA address values are ignored.

          If no matching policy can be found, the data MUST be discarded
          immediately, and this event MAY be logged as reception of an
          invalid SNDU.

     If the SNDU is received without a security extension header but
      the SP does not permit unprotected data to pass, the SNDU MUST be
      discarded immediately, and this event SHOULD be logged as
      reception of an invalid SNDU. Likewise, if there is a security
      extension header but the policy allows only for unprotected data,
      the SNDU MUST be discarded, and this event SHOULD be logged.

     When permitted, an SNDU without a security extension header is
      decoded as usually. For a protected SNDU, processing continues
      with step 3.

   3. Get SA: With a first match on a SP, a SA Selector is constructed
      to find a SA within the SAD.


Noisternig            Expires January 14, 2009               [Page 21]


Internet-Draft A lightweight security extension for ULE       July 2008


        a.               D=0: With a destination address present, the following SA
          Selector is used to directly look up a SA within the SAD:

          SA Selector := (SNDU's Basic Selector data AND SP's SA
          Selector Mask, SP's SA Selector Mask, SNDU's VPN-ID value)

          The VPN-ID value must be set to a reserved value if not
          defined by a ULEsec_ID header.

          If no SA is found, it must be tried to set it up as described
          in step 2 of section 4.2, Sender Processing. If creation of a
          SA fails, the SNDU MUST be discarded, and this SHOULD be
          logged accordingly.

        b.               D=1: With the D bit set, a set of SAs is looked up by omitting
          the destination address:

          SA Selector := (SNDU's PID AND SP's SA Selector Mask's PID,
          SP's SA Selector Mask, SNDU's VPN-ID value)

          From the retrieved set, every SA not defining identity
          protection is ignored. Assuming the remaining set is not
          empty, the K Bit and Encrypted Destination Address field are
          read ahead from the security extension header. The current
          key, as defined by the K Bit (see next step), is then taken
          from the first SA in the set to trial-decrypt the Encryption
          Destination Address field (i.e., it is decrypted to a
          temporary buffer). The decrypted address MUST be checked to
          match both the SP selected as well as belong to the current
          SA. Then, it MUST be compared with all destination NPA
          addresses a receiver accepts to look for a match. If either a
          SA does not contain the current key, or there is no match for
          an address, the SA is removed from the retrieved set, and
          probing is done with the next one.

          If no SA matches, but the SP defines default key data as well
          as the identity protection service for the first set of
          Security Parameters, the encryption key derived from the
          default key data is used for probing with the SNDU as
          described in above paragraph. (Because of this, receiver-side
          SPs containing default key material SHOULD already provide
          derived keys for efficiency reasons.) If this test succeeds, a
          SA is constructed using the SP's first Security Parameter set;
          if SA creation fails (e.g., due to out-of-memory conditions),
          the SNDU MUST be discarded, and this SHOULD be logged
          accordingly.



Noisternig            Expires January 14, 2009               [Page 22]


Internet-Draft A lightweight security extension for ULE       July 2008


          When no matching SA can be found, the SP is assumed to be
          selected mistakenly, and processing MUST continue at step 2.b
          with the next SP in the list of incoming SPs.

   4. Select key: Once a matching SA is found, proper keys must be
      looked up. For this, the SNDU's K bit is compared with the SA's
      receiver-side one. If they are equal, the SA's current keys are
      taken for decoding. Otherwise, the SA's prospective keys must be
      selected. If these are not defined, the SNDU MUST be discarded and
      this event SHOULD be logged as reception of an invalid SNDU. A
      receiver SA, when provided with prospective keys, must switch to
      these after a policy-defined point or amount of time by flipping
      its receiver-side K bit and replacing the current keys with the
      fresh ones.

   5. Decode SNDU (2):

        a.               Authenticate SNDU: For verifying authenticity and integrity, a
          MAC is computed as defined for the sender side, and then
          compared with the value of the SNDU's MAC field for equality.
          If the two values differ, the SNDU MUST be discarded, and this
          SHOULD be logged as a data authentication failure.

        b.               Replay Protection: To detect replays, the SNDU's Sequence
          Number MUST be greater than or equal to the SA's receiver-side
          sequence number; if this is not the case, the SNDU MUST be
          discarded, and this event SHOULD be logged as a replay.

        c.               Decryption: If the data confidentiality service is used, all
          data starting from the security extension header's Encrypted
          Type field up to the end of the PDU data are decrypted. After
          that, processing continues as normally (i.e., any other
          extension headers are evaluated, and the PDU is finally passed
          to upper protocol layers).

   6. Update SA: Now that the SNDU has been accepted, a SA using replay
      protection must be updated accordingly: If the K bits of step 4
      were differing, keys are switched immediately as described in that
      step; then, the SA's receiver-side sequence number is set to the
      SNDU's Sequence Number value, and incremented by 1.

5. Key Management Considerations

   Manual key setup is simple but practical only for small and
   relatively static secure groups. When number of receivers gets high,
   or users need to be added or excluded more frequently, automated key
   management becomes necessary. A Group Controller and Key Server


Noisternig            Expires January 14, 2009               [Page 23]


Internet-Draft A lightweight security extension for ULE       July 2008


   (GCKS) uses a key management protocol to automatically distribute key
   material to legitimate devices in the event of new membership,
   revoking of users, or key update (either periodically for increased
   security, or after a security breach). The definition or selection of
   any particular key management protocol is out of scope for this
   document as doing so has no influence on extension header format,
   security algorithms, or extension header processing. However, some
   important considerations are discussed next, and one must distinguish
   between the two different scenarios of unidirectional and
   bidirectional communication.

5.1. Unidirectional Key Management

   In unidirectional settings, security parameters can merely be decided
   by the sender. Having no way for negotiation, this allows for a
   simpler protocol design in this regard. However, other issues arise.
   Senders must assure reliable delivery of information to all
   receivers. Doing so might require sending the same data multiple
   times. Receivers must be able to jump into a session at any time and
   without substantial delays, either when they are turned on, or after
   loss of synchronization. Replay attacks must be considered. They are
   best countered with timestamps; however, this requires sender and
   receivers to have synchronized clocks.

   The design of a unidirectional key management protocol should allow
   installing, updating, and revoking a number of different keys within
   receiver devices, with new keys encrypted with any other one.
   Different keys can correspond to individual, group, or global keys.
   This flexibility will allow the use of various broadcast encryption
   algorithms (such as the subset difference scheme [Subset]).

   It is further suggested that a unidirectional key management protocol
   uses the same format for re-key messages as for the initial key
   distribution. In other words, re-keys should provide all the
   information necessary to allow receivers to jump into the middle of a
   session, which shall result in great aid for connectivity.

   Existing mechanisms should be evaluated, such as [DVB-CA] and [ATSC-
   CA]. For example, [DVB-CA] defines unidirectional key management in
   the form of the entitlement checking and entitlement management
   messages. This offers a simple mechanism for securely establishing,
   updating, and revoking keys. A 3-level key hierarchy is used to
   provide for a better level of safety in case of key compromise.
   However, the single first-level key remains unchanged, constituting a
   weakness in this system; this could be mitigated in a protocol for
   the ULE security extension by either configuring receiver devices
   with unique sets of first level keys, thereby allowing true broadcast


Noisternig            Expires January 14, 2009               [Page 24]


Internet-Draft A lightweight security extension for ULE       July 2008


   encryption algorithms such as [Subset], or by permitting operators of
   a VPN to update first level keys externally of the ULE network
   (either manually or automatically).

5.2. Bidirectional Key Management

   The availability of a back channel allows devices not only to
   actively request group membership, revocation, and retransmission of
   keys after loss of synchronization. Negotiation of cryptographic
   algorithms and keys becomes possible, as well as enhanced security
   features such as perfect forward secrecy, mutual authentication, and
   identity protection when receivers are identified by other means than
   their NPA address.

   In contrast to unidirectional key management, numerous bidirectional
   protocols have been developed for various layers of the ISO/OSI
   reference model. Prominent examples include [DVB-RCS] (link layer),
   IKEv2/IPsec [RFC4306] (network layer), TLS [RFC4346] (transport
   layer) and SSH [RFC4253] (application layer). Naturally, they differ
   highly in purpose, functionality, and complexity. While existing link
   layer technology such as those within [DVB-RCS] is probably most
   directly usable for ULE, requirements for bidirectional key
   management must be clearly determined.

   Traditional key management protocols, including the ones cited above,
   are designed for unicast communication, only. ULE key management must
   support VPN-like settings with a potentially large number of
   receivers. One focus of the IETF MSEC working group is on developing
   and standardizing scalable solutions for key management within large
   groups, and several different protocols have been proposed [RFC4535,
   RFC3547, GKDP, FMKE, RFC3830]). Clearly, these must be considered
   when defining ULE key management.

6. Security Considerations

   The security of cryptography-based systems depends in one part on the
   strength of the cryptographic algorithms chosen and the strength of
   the keys used with those algorithms. The algorithms identified in
   this document are not known to be broken at the current time, and
   research so far leads to believe that the combination of algorithms
   and key lengths specified within this document will likely remain
   secure into the foreseeable future. Considerations that relate to
   this aspect, including the correct use of algorithms, are addressed
   in their respective sections or the appendices of this document.

   There is a caveat regarding the security extension's Sequence Number
   field when a SA secures communication for a single receiver device


Noisternig            Expires January 14, 2009               [Page 25]


Internet-Draft A lightweight security extension for ULE       July 2008


   (i.e. for unicast communication) and the identity protection service
   is used. A passive attacker may link SNDUs with increasing sequence
   number to the same SA, thereby increasing its chance of identifying a
   receiver and the amount and type of data transmitted to it. Future
   research will investigate on possible solutions for this problem.

   The security also depends on the engineering and administration of
   the protocols used by the system to ensure that there are no non-
   cryptographic ways to bypass security. When selecting a key
   management protocol, its security will be a pre-requirement for
   overall system security.

   ULE link layer security may not be treated as a replacement for end-
   to-end security. If reliable security is required, one MUST use end-
   to-end security protocols. However, ULE link layer security can
   complement end-to-end security as laid out in the conclusions in
   section 8.

7. IANA Considerations

   This document requires two 16-bit Type codes to be registered by the
   IANA, namely one for the ULEsec security extension, and one for the
   ULEsec_ID extension header type. It is suggested that the two Type
   codes are allocated in a way that they differ only in their least-
   significant bit. This allows use of this bit as a flag for
   determining the presence of the VPN-ID field. (However, this is
   merely an optimization and no requirement.)

8. Conclusions

   The solution presented within this document addresses many of the
   security requirements for the ULE protocol laid out in the separate
   security requirements document. Passive attacks, constituting the
   most important threats in the ULE network, are effectively defeated
   using the data confidentiality and identity protection service. To
   mitigate active attacks, MACs may be used to assure a receiver of the
   authenticity and integrity of the data received. While not providing
   source authentication for VPN-like settings with multiple senders,
   they still render outsider attacks futile. Sequence numbers within
   each SNDU allow for simple detection of replayed data on unicast
   connections, without any additional bandwidth overhead.

   The format of the security extension header generates minimal
   bandwidth overhead, is extensible, and acts as a framework for a set
   of security transforms that may be changed and updated independently
   of each other. Default algorithms are defined to be lightweight and
   allow implementation in low-cost devices.


Noisternig            Expires January 14, 2009               [Page 26]


Internet-Draft A lightweight security extension for ULE       July 2008


   A key management protocol may be added later and independently of
   this specification. This will allow more flexibility and security in
   setting up secure connections and VPNs. Existing protocols such as
   those following the guidelines of [RFC4046] might be used. However,
   this will need careful assessment regarding the applicability for the
   ULE link.

   Note that the presented ULE security extension secures the ULE
   broadcast link, only, and as such may not be treated as a replacement
   for end-to-end security. In fact, ULE link layer security is an
   additional security mechanism that complements end-to-end security
   [ULEsec-Req]. Where end-to-end security is used, it can provide
   identity protection over the ULE link in addition. When the ULE link
   is used to directly connect two secure sites, ULEsec can be the sole
   provider of security. In the cases where end-to-end security is not
   applicable, the ULE security extension can be viewed as protecting
   the weakest link, and a user can rely on security assumptions as of
   wired links.

9. Acknowledgments

   The document was prepared using 2-Word-v2.0.template.dot.


























Noisternig            Expires January 14, 2009               [Page 27]


Internet-Draft A lightweight security extension for ULE       July 2008


APPENDIX A: Rationale for the Extension Header Format

A.1. (16-bit) optional VPN-ID vs. (32-bit) SPI

   In order to identify which secure connection (represented by a SA) a
   secured packet belongs to, it is generally marked with a connection
   identifier. For the IPsec [RFC4301] security protocols, this
   identifier is known as the Security Parameter Index (SPI). It is
   selected by the receiver, only, in order to avoid collisions between
   different connections. This works because IPsec is designed for
   secure unicast communication only. For multicast settings, a manually
   assigned SPI together with manual keying can be used. The same
   principle of deriving a secure connection identifier can be used with
   the ULE security extension, too. Instead of an SPI, the ULE security
   extension provides the VPN-ID field, when the ULEsec_ID security
   extension header type is used.

   One difference between IPsec and ULEsec is that IPsec is an end-to-
   end security protocol. This means that on a single ULE link a ULE
   decapsulator will potentially accept data from many different (IPsec)
   end-to-end connections. In contrast, at the ULE link layer users are
   expected to establish just a single or otherwise so few secure L2
   connections that in many cases receivers can even identify
   connections based on ULE destination NPA addresses and MPEG-2 TS PID
   values alone. Therefore, a size of 16 bits has been chosen for the
   ULEsec VPN-ID field as opposed to 32 bits as used for the SPI of the
   IPsec security protocols. In addition, it is provided for a way to
   omit the VPN-ID field altogether (by selecting the ULEsec extension
   header type).

A.2. VPN-ID + K-Bit vs. SPI

   The way re-keying works in the IPsec protocols is by creating a new
   SA (i.e., secure connection) for the new keys. The new SA will have a
   different SPI value than the old one, selected by the receiver again.
   This model does not work for ULE, however. A receiver that failed to
   receive key update messages will have no way of determining that the
   new data with a different secure connection identifier is to be
   received by him. This is not only an issue for multicast settings
   where scalability is a concern, but also for unidirectional links
   where there is no way for feedback. Instead, ULEsec uses the K Bit to
   signal when re-keying occurred, and keeps the VPN-ID value constant.
   Now a receiver will always know which data to accept, and it would
   have to lose key management messages during two periods of key
   updates for this model to fail.




Noisternig            Expires January 14, 2009               [Page 28]


Internet-Draft A lightweight security extension for ULE       July 2008


A.3. 31-bit/63-bit Sequence Number

   A 31-bit sequence number has been chosen as a default as it does not
   add too much overhead and is reasonably big for automated re-keying
   to happen infrequently. For example, when SNDUs are continuously sent
   on a link with an effective bit rate as high as 68 Mbit/s [DVB-S],
   protected under the same key, and contain only TCP/IP acknowledgments
   so the SNDU size is just 60 octets (20 octets ULE+ULEsec header, 20
   octets IP header, and 20 octets TCP header), then a key can still be
   used for more than four hours before the 31-bit sequence number space
   will be exhausted.

   For high-speed links, and when manual keying is used, the larger 63-
   bit sequence numbers are to be used. This pairs well with a key size
   of 128 bits for the encryption algorithm, where after 2^63 uses
   security will be about halved and new keys should be set up by then.

   While the Sequence Number field could be optional, too, its placement
   has been made mandatory in order to not unnecessarily complicate
   things, and since it is required virtually always, anyway. It could
   be replaced with a timestamp, though, but this is not defined within
   this specification.

A.4. MAC field

   The MAC field is not a direct part of the security extension header,
   but defined as a trailer. This allows the MAC to be computed in an
   online way. For example, a sender can compute the MAC of an SNDU
   while it is already transmitting it, and when it has sent the last
   bit of the payload it can simply attach the MAC.

   For a similar reason, the CRC, which can be viewed as part of the ULE
   base header, is at the end of the SNDU.















Noisternig            Expires January 14, 2009               [Page 29]


Internet-Draft A lightweight security extension for ULE       July 2008


APPENDIX B: Rationale for the Default Security Algorithms

B.1. Encryption

   The first question on the data confidentiality service is whether to
   use a block cipher or a stream cipher algorithm. Stream ciphers offer
   the benefit of allowing for very simple and fast implementations. One
   particular stream cipher is the Arcfour (or RC4) algorithm [Arcfour],
   and it can be regarded the de-facto standard among software based
   implementations. However, several weaknesses have been found so far,
   and while there are ways to circumvent some of them, they do not make
   Arcfour a favorable choice [Arcfour-Fix]. Unfortunately, other stream
   ciphers available are either not sufficiently analyzed, or are based
   on linear feedback shift registers, making them suitable for cheap
   hardware implementations but vulnerable to algebraic attacks.

   Among block ciphers, things are looking much better. The Advanced
   Encryption Standard (AES) [AES] has been quickly embraced as a
   secure, fast, and open encryption algorithm since its election within
   a competition held by the American NIST in the year 2000 to replace
   the aging DES. Despite algebraic structures found, AES is still
   considered secure.

   A mode of operation is required for a block cipher to allow it to be
   repeatedly used securely under the same key. NIST has standardized
   several such modes [Modes]. One particular mode is the Cipher Block
   Chaining (CBC) mode. It is well-understood and has good security
   properties. However, it operates on full blocks only, and data must
   therefore be padded to multiples of block lengths in general. In
   addition, the CBC mode requires an explicit (pseudo-)random
   Initialization Vector (IV) of the size of a cipher block for each
   packet. This is clearly wasteful for the ULE scenario, where this
   means additional average overhead of 24 octets per SNDU when used
   with AES.

   The Counter (CTR) mode in contrast effectively turns the block cipher
   into a stream cipher, so there is no need for padding. IVs for this
   mode come as nonces, so a simple counter may be used. A counter can
   not only be encoded in less space than the size of a cipher block, it
   may also serve as a mechanism for replay protection - in which case
   no space will be wasted at all. Some of the other advantages of the
   CTR mode are that only the encryption part of the block cipher
   algorithm is needed, and both encryption and decryption can be
   parallelized.

   Strong care must be taken for the nonces to never be used twice under
   the same key, or all security will be lost. Therefore, within the


Noisternig            Expires January 14, 2009               [Page 30]


Internet-Draft A lightweight security extension for ULE       July 2008


   construction of the nonce, not only the SNDU's sequence number but
   also the MPEG-2 TS cell's PID value is included. This gives a
   guarantee for nonces to be unique when the encryption key is shared
   across more than one PID. One case is that of multiple senders (i.e.
   ULE encapsulators) using the same keys. It is assumed that there will
   be at most one sender per PID for technical reasons (this does not
   preclude the possibility of adversaries sending on the same PID). A
   similar scenario is where a sender spreads data over multiple PIDs.

   The last question is what key size to use. AES may be used with key
   sizes of 128, 192, or 256 bits. Of these, 128 bits are regarded to be
   sufficiently secure even for the foreseeable future, and any bigger
   size would merely result in increased key management overhead and
   computational effort [Standards].

B.2. Identity protection

   The presented solution for identity protection is simple, yet very
   effective. First, a receiver needs to probe only a very low number of
   keys with an SNDU. This is because in the vast majority of cases
   there is only a single or otherwise very few different keys a
   receiver associates with a PID or pair of PID and VPN-ID field: For
   an incoming ULEsec packet with a VPN-ID field present, the pair of
   PID and VPN-ID will most commonly denote a single VPN with a single
   shared key. Without a VPN-ID, the PID may represent a VPN with a
   single key, or the PID will probably contain several or many unicast
   or multicast connections of which the receiver accepts only a few,
   namely for its own unicast and a few (if any) multicast addresses.
   Each of these connections could utilize identity protection; however,
   this is sensible only for unicast communication. Assuming a device is
   not assigned more than one unicast address, there is only a single
   key left that has to be probed with.

   Second, by encrypting the address an adversary not in the know of a
   matching decryption key will not be able to read the packet's
   destination address. A legitimate receiver, in contrast, will
   correctly decode the address with very high probability. In detail,
   the chance that an SNDU is mistakenly accepted (assuming the
   encryption algorithm behaves as a pseudo-random function under
   different keys) is given approximately by k*10^-14.4, where k is the
   receiver's number of keys that do not match. This is close to typical
   packet-error ratios on the ULE link for small k, as this example
   shows: assuming a quasi-error free channel with a bit-error ratio of
   10^-10 [DVB-S], and - for simplicity assumed - a probability of 2^-32
   for the CRC-32 failing, the chance of receiving an erroneous SNDU
   undetected by the CRC ranges between approximately 10^-15.5 for a



Noisternig            Expires January 14, 2009               [Page 31]


Internet-Draft A lightweight security extension for ULE       July 2008


   typical 1500-octet (file download) payload and 10^-16.8 for small
   (VoIP) data of 60 octets.

   Note that this method of identity protection requires to be combined
   with the data confidentiality service for two reasons: First, it
   protects only L2 addresses. Second, there is a requirement for the
   data a receiver assumes to be an encrypted destination address to be
   pseudo-random, or at least non-repeating (with high probability),
   otherwise above equations will not hold.

   This solution for identity protection is also superior to other
   suggestions such as the use of temporary destination addresses
   [ULEsec-CPI] for a variety of reasons. First, when creating temporary
   addresses it must somehow be assured that these do not and will not
   collide with real-world addresses, i.e. addresses that are in use or
   might be used in the future. Second, in order to assure these
   addresses to be unique a server must keep every one of them in a
   database. This is clearly a disadvantage for simple settings such as
   VPNs where otherwise only a single key must be stored. Third, such
   addresses compromise additional information that must be distributed
   in a reliable way, which is difficult for unidirectional links and
   does not scale well for multicast scenarios. Last but not least, even
   though these addresses are temporary, they remain constant for a
   period of time and as such may pose just another chance for an
   adversary to link packets with a receiver.

B.3. Authentication

   By adding redundancy in the form of keyed cryptographic checksums to
   packets, legitimate receivers can verify both authenticity and
   integrity of the data. A Message Authentication Code (MAC) is the
   result of a symmetric checksum function, so both senders and
   receivers use the same key for authenticating and verifying.

   MAC algorithms typically build upon cryptographic hash functions
   (message digests), such as MD5 [RFC1321], SHA-1 and the SHA-2 family
   [SHA], and RIPEMD-160 [RIPEMD-160]. The HMAC [RFC2104] is a popular
   construction to turn a hash function into a MAC function. The
   advantage of using hash functions is their simple implementability,
   resulting in certain speed advantages. Despite a number of surprising
   and unexpected collision attacks on hash functions published lately
   [MD5-Attack, SHA-1-Attack], the HMAC construction is secure as long
   as no second pre-image attacks become practical, and the hash
   function's output cannot be distinguished from random data by an
   adversary [Preimages, HMAC2, Standards].




Noisternig            Expires January 14, 2009               [Page 32]


Internet-Draft A lightweight security extension for ULE       July 2008


   MAC constructions may also use block ciphers as building blocks. The
   main advantage of this approach is that an already existing block
   cipher implementation can be re-used. This makes the CBC-MAC (and its
   variants) still a very popular solution. The security of a CBC-MAC is
   directly dependent on that of the block cipher. Because of the
   birthday phenomenon, the upper limit of security is also determined
   by the block length of the underlying encryption algorithm, which
   degrades quadratically over time [CBCMAC1, CBCMAC2]. Therefore, when
   the same key is used for a long time (e.g., with extended sequence
   numbers for ULEsec), a cipher with a higher block length should be
   chosen, such as [Rijndael] with a block length of 256 bits.

   A plain CBC-MAC is not a generally secure construction. In detail, it
   is only secure for fixed-size or prefix-free messages [CBCMAC1].
   However, ULE SNDUs are automatically prefix-free because of the
   inclusion of the length field in the base header.

   There are some interesting newer constructions based on Carter-Wegman
   universal hashing, such as the UMAC [RFC4418] and the [Poly1305-AES],
   both defined for use with the AES encryption algorithm. While having
   excellent security properties, allowing for parallelization, and
   achieving high throughputs on modern desktop processors, they are not
   suitable for small hardware devices because of performing complex
   operations such as multiplications in large size Galois fields and
   requiring a large amount of memory.

   Two surprisingly simple and parallelizable designs are presented in
   [XOR-MAC] and [PMAC]. When a block cipher is plugged into the pseudo-
   random function required, the complexity is similar to that of the
   CBC-MAC. Security is not affected by the birthday phenomenon,
   however. As both algorithms are covered by patents, they are not
   selected as default authentication algorithms.

B.4. Source Authentication

   MAC algorithms are symmetrical functions, so anyone in the know of
   the right key could have been the author of an authenticated message.
   Consequently, MACs cannot provide source authentication when there is
   more than one legitimate sender, or receivers are able to act as
   senders. In order to guarantee data coming from the source as
   corroborated, some asymmetry must be introduced, either by using
   functions that are hard to invert (digital signatures), or by
   disclosing verification key material only after it has been used for
   authentication (e.g., TESLA [RFC4082]).

   Source authentication does not come for free, however. Digital
   signature algorithms are very computationally demanding, as time


Noisternig            Expires January 14, 2009               [Page 33]


Internet-Draft A lightweight security extension for ULE       July 2008


   needed for signing and verification is still counted in milliseconds
   even on modern hardware. Additionally, bandwidth consumption is high
   with typical key sizes of 1024 bits and signature sizes of 320 bits
   for a level of security comparable to that of a 80-bit symmetric key
   [Recommendations]. A number of different solutions have been
   developed over time to overcome these shortcomings, most prominently
   TESLA; however, all of them have one or another drawback such as
   increased latency at the sender or receiver side, lack of re-
   synchronization ability in case of packet loss, or even higher
   bandwidth cost.

   Source Authentication for ULEsec may be devised independently of this
   specification, but it likely makes more sense for control messages
   (e.g., key management messages).

B.5. Combined Authentication and Encryption

   While there had always been a lack of consensus in cryptography and
   security communities about the "right" way of combining
   authentication with encryption, it had not been know until recently
   that the only generally secure way of generic composition is Encrypt-
   then-Authenticate (EtA) [Order-AE]. By following that finding within
   this specification, encryption and authentication algorithms can be
   changed and updated independently of each other without compromising
   overall security; for example, the default CBC-MAC for authentication
   could safely be replaced with a MAC using a cryptographic hash
   function, or with an algorithm providing source authentication for
   multi-sender scenarios.

   Another recent development in cryptography are so-called
   Authenticated Encryption (AE) and Authenticated Encryption with
   Associated Data (AEAD) schemes. These can be viewed as modes of
   operation that integrate both authentication and encryption
   functionality. Excitement for these schemes can primarily be
   contributed to the development of encryption modes that provide
   authentication essentially for free (i.e., with negligible
   computational overhead) [IAPM, XCBC, OCB]. Unfortunately, all these
   so-called 1-pass schemes have patents filed on them, which is an
   issue for an open standard. This circumstance initiated the
   development of second-generation unpatented 2-pass schemes, most
   notably CCM [CCM]. Even though these modes provide a secure two-in-
   one solution (one key for both encryption and authentication), they
   have lost their predecessors' main advantage: they are, as their name
   says, 2-pass. As a result, they do not offer any real benefits over
   the more versatile AtE generic composition approach.




Noisternig            Expires January 14, 2009               [Page 34]


Internet-Draft A lightweight security extension for ULE       July 2008


B.6. Replay Protection

   The key idea in providing replay protection is to guarantee each
   packet to be unique under the same key. This is generally achieved by
   adding a monotonically increasing counter or a timestamp to the
   packet header. The in-order delivery of data on the ULE link then
   allows for easy detection of replays on the receiver side.

   A counter is simple to use, requires minimal connection state on each
   side, and is fully reliable for unicast connections and other one-
   sender scenarios. It cannot be used when a key is shared among
   multiple senders due to the difficulty of synchronizing replay state.

   A timestamp uses synchronized clocks for the replay state. A small
   window of accepted timestamps is required to compensate timing
   discrepancies. This way, timestamps can be used with any number of
   senders. However, this also means that they are not completely
   reliable; consequently, their use is not defined within that
   specification.





























Noisternig            Expires January 14, 2009               [Page 35]


Internet-Draft A lightweight security extension for ULE       July 2008


10. References

10.1. Normative References

   [RFC4326] G. Fairhurst, B. Collini-Nocker, "Unidirectional
             Lightweight Encapsulation (ULE) for Transmission of IP
             Datagrams over an MPEG-2 Transport Stream (TS)", IETF RFC
             4326, December 2005.

   [MPEG2]  "Information technology - generic coding of moving pictures
             and associated audio information systems, Part I", ISO
             13818-1, International Standards Organization (ISO), 2000.

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, IETF RFC 2119, March 1997.

   [AES]    "Advanced Encryption Standard (AES)", FIPS PUB 197,
             National Institute of Standards and Technology (NIST), Nov.
             2001.

   [Modes]  M. Dworkin, "Recommendation for Block Cipher Modes of
             Operation - Methods and Techniques", SP 800-38A, National
             Institute of Standards and Technology (NIST), Dec. 2001.

10.2. Informative References

   [H222]   "Information technology, Generic coding of moving pictures
             and associated audio information Systems", H.222.0,
             International Telecommunication Union (ITU-T), 1995.

   [DVB-S]  "Digital Video Broadcasting (DVB); Framing structure,
             channel coding and modulation for 11/12 GHz satellite
             systems", ETSI EN 300 421, Aug. 1997.

   [DVB-T]  "Digital Video Broadcasting (DVB); Framing structure,
             channel coding and modulation for digital terrestrial
             television", ETSI EN 300 744, June 2006.

   [DVB-H]  "Digital Video Broadcasting (DVB); Transmission system for
             handheld terminals (DVB-H)", ETSI EN 302 304, Nov. 2004.

   [ULEsec-Req]H. Cruickshank, P. Pillai, M. Noisternig, S. Iyengar,
             "Security requirements for the Unidirectional Lightweight
             Encapsulation (ULE) protocol", draft-ietf-ipdvb-sec-req-08
             (work in progress), July 2008.




Noisternig            Expires January 14, 2009               [Page 36]


Internet-Draft A lightweight security extension for ULE       July 2008


   [GSE]    "Generic Stream Encapsulation (GSE) Protocol", DVB BlueBook
             A116, May 2007.

   [RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet
             Protocol", IETF RFC 4301, Dec. 2005.

   [RFC4346] T. Dierks, E. Rescorla, "The Transport Layer Security (TLS)
             Protocol Version 1.1", IETF RFC 4346, April 2006.

   [RFC4253] T. Ylonen, C. Lonvick, "The Secure Shell (SSH) Transport
             Layer Protocol", IETF RFC 4253, Jan. 2006.

   [RFC3819] P. Karn, C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig,
             J. Mahdavi, G. Montenegro, J. Touch, L. Wood, "Advice for
             Internet Subnetwork Designers", IETF RFC 3819, July 2004.

   [Rijndael]J. Daemen, V. Rijmen, "The Design of Rijndael: AES - The
             Advanced Encryption Standard", Springer Verlag, March 2002,
             pp. 238.

   [Subset] D. Naor, M. Naor, J. Lotspiech, "Revocation and Tracing
             Schemes for Stateless Receivers", Advances in Cryptology -
             CRYPTO 2001, 21st Annual International Cryptology
             Conference, Proceedings, August 2001, pp. 41-62.

   [DVB-CA] "Digital Video Broadcasting (DVB); Support for Use of
             Scrambling and Conditional Access (CA) within Digital
             Broadcasting Systems", ETSI ETR 289, Jan. 1996.

   [ATSC-CA] "Conditional Access System for Terrestrial Broadcast,
             Revision A, with Amendment No. 1", Doc. A/70A, Advanced
             Television Systems Committee, July 2004 (Sept. 2006 for
             Amendment No. 1).

   [DVB-RCS] "Digital Video Broadcasting (DVB); Interaction Channel for
             Satellite Distribution Systems", ETSI EN 301 790, Sept.
             2005.

   [RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", IETF
             RFC 4306, Dec. 2005.

   [RFC4046] M. Baugher, R. Canetti, L. Dondeti, F. Lindholm, "Multicast
             Security (MSEC) Group Key Management Architecture", IETF
             RFC 4046, April 2005.





Noisternig            Expires January 14, 2009               [Page 37]


Internet-Draft A lightweight security extension for ULE       July 2008


   [RFC4535] H. Harney, U. Meth, A. Colegrove, G. Gross, "GSAKMP: Group
             Secure Association Key Management Protocol", IETF RFC 4535,
             June 2006.

   [RFC3547] M. Baugher, B. Weis, T. Hardjono, H. Harney, "The Group
             Domain of Interpretation", IETF RFC 3547, July 2003.

   [RFC3830] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman,
             "MIKEY: Multimedia Internet KEYing", IETF RFC 3830, August
             2004.

   [GKDP]   L. Dondetti, J. Xiang, S. Rowles, "GKDP: Group Key
             Distribution Protocol", IETF draft-ietf-msec-gkdp-01
             (expired), March 2006.

   [FMKE]   L. Duquerroy, S. Josset, "The Flat Multicast Key Exchange
             protocol", draft-duquer-fmke-01 (expired), Sept. 2004.

   [RFC4082] A. Perrig, D. Song, R. Canetti, J. Tygar, B. Briscoe,
             "Timed Efficient Stream Loss-Tolerant Authentication
             (TESLA): Multicast Source Authentication Transform
             Introduction", IETF RFC 4082, June 2005.

   [RFC4082] A. Perrig, D. Song, R. Canetti, J. D. Tygar, B. Briscoe,
             "Timed Efficient Stream Loss-Tolerant Authentication
             (TESLA): Multicast Source Authentication Transform
             Introduction", IETF RFC 4082, June 2005.

   [Arcfour] B. Schneier, "Applied Cryptography Second Edition:
             protocols algorithms and source in code in C", John Wiley
             and Sons, New York, 1996.

   [Arcfour-Fix] B. Harris, "Improved Arcfour Modes for the Secure
             Shell (SSH) Transport Layer Protocol", IETF RFC 4345, Jan.
             2006.

   [Standards] B. Burr, "NIST Cryptographic Standards Status Report",
             PowerPoint presentation, National Institute of Standards
             and Technology (NIST), April 2006.

   [ULEsec-CPI]H. Cruickshank, P. Pillai, S. Iyengar, "Security
             Extension for Unidirectional Lightweight Encapsulation
             Protocol", draft-cruickshank-ipdvb-sec-03 (work in
             progress), July 2007.

   [RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", IETF RFC
             1321, April 1992.


Noisternig            Expires January 14, 2009               [Page 38]


Internet-Draft A lightweight security extension for ULE       July 2008


   [SHA]    "The Secure Hash Standard", FIPS 180-2 (+ change notice to
             include SHA-224), National Institute of Standards and
             Technology (NIST), August 2002.

   [RIPEMD-160]H. Dobbertin, A. Bosselaers, B. Preneel, "RIPEMD-160: A
             Strengthened Version of RIPEMD",
             http://homes.esat.kuleuven.be/~bosselae/ripemd160.html,
             April 1996.

   [RFC2104] H. Krawczyk, M. Bellare, M. and R. Canetti, "HMAC: Keyed-
             Hashing for Message Authentication", IETF RFC 2104, Feb.
             1997.

   [CBCMAC1] M. Bellare, J. Kilian, P. Rogaway, "The security of the
             cipher block chaining message authentication code", Journal
             of Computer and System Sciences, Vol. 61, No. 3, Dec. 2000,
             pp. 362-399.

   [CBCMAC2] B. Preneel, P. C. van Oorschot, "MDx-MAC and building fast
             MACs from hash functions", Proc. Crypto '95: 15th Annual
             International Cryptology Conference, Santa Barbara, Aug.
             1995.

   [RFC4418] T. Krovetz, "UMAC: Message Authentication Code using
             Universal Hashing", IETF RFC 4418, March 2006.

   [Poly1305-AES] D. Bernstein, "The Poly1305-AES Message-Authentication
             Code", Proceedings of Fast Software Encryption, Lecture
             Notes in Computer Science, Springer-Verlag, 2005.

   [XOR-MAC] M. Bellare, R. Guerin, P. Rogaway, "XOR MACs: New methods
             for message authentication using finite pseudorandom
             functions", Advances in Cryptology - Crypto 95 Proceedings,
             Lecture Notes in Computer Science, Springer-Verlag, 1995.

   [PMAC]   J. Black, P. Rogaway, "A Block-Cipher Mode of Operation for
             Parallelizable Message Authentication", Advances in
             Cryptology - EUROCRYPT '02, Lecture Notes in Computer
             Science, Springer-Verlag, 2002.

   [DSS]    "Digital Signature Standard (DSS)", FIPS PUB 186-2 (+
             change notice), National Institute of Standards and
             Technology (NIST), Jan. 2000.






Noisternig            Expires January 14, 2009               [Page 39]


Internet-Draft A lightweight security extension for ULE       July 2008


   [Order-AE]H. Krawczyk, "The order of encryption and authentication
             for protecting communications", Proc. Crypto 2001: 21st
             Annual International Cryptology Conference, Santa Barbara,
             Aug. 2001.

   [IAPM]   C. Jutla, "Parallelizable Encryption Mode with Almost Free
             Message Integrity", NIST proposed mode.
             http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_developmen
             t.html

   [XCBC]   V. Gligor, P. Donescu, "Fast Encryption and Authentication:
             XCBC Encryption and XECB Authentication Modes", NIST
             proposed mode, April 2001.
             http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_developmen
             t.html

   [OCB]    P. Rogaway, M. Bellare, J. Black, T. Krovetz, "OCB: A
             Block-Cipher Based Mode of Operation for Efficient
             Authenticated Encryption", NIST proposed mode, August 2001.
             http://csrc.nist.gov/groups/ST/toolkit/BCM/modes_developmen
             t.html

   [CCM]    D. Whiting, R. Housley, N. Ferguson, "AES Encryption &
             Authentication using CTR Mode & CBC-MAC", IEEE P802.11
             802.11-02/001r0, Jan. 2002.

   [MD5-Attack]X. Wang, D. Feng, X. Lai, H. Yu, "Collisions for Hash
             Functions MD4, MD5, HAVAL-128 and RIPEMD", Cryptology
             ePrint Archive: Report 2004/199, August 2004.

   [SHA-1-Attack] X. Wang, Y. Yin, H. Yu, "Finding Collisions in the
             Full SHA-1", Advances in Cryptology - Crypto 2005
             Proceedings, Lecture Notes in Computer Science, Springer-
             Verlag, Aug. 2005.

   [Preimages] J. Kelsey, B. Schneier, "Second Preimages on n-bit Hash
             Functions for Much Less than 2^n Work", Cryptology ePrint
             Archive: Report 2004/304, Nov. 2004.

   [HMAC2]  M. Bellare, "New Proofs for NMAC and HMAC: Security without
             Collision-Resistance", Advances in Cryptology - Crypto 2006
             Proceedings, Lecture Notes in Computer Science Vol. 4117,
             Springer-Verlag, Sept. 2006.

   [Recommendations] "Recommendation for Key Management - Part 1:
             General (Revised)", SP 800-57, National Institute of
             Standards and Technology (NIST), May 2006.


Noisternig            Expires January 14, 2009               [Page 40]


Internet-Draft A lightweight security extension for ULE       July 2008


Author's Addresses

   Michael Noisternig
   University of Salzburg
   Jakob-Haringer-Str. 2
   5020 Salzburg
   Austria

   Email: mnoist@cosy.sbg.ac.at


   Bernhard Collini-Nocker
   University of Salzburg
   Jakob-Haringer-Str. 2
   5020 Salzburg
   Austria

   Email: bnocker@cosy.sbg.ac.at


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.






Noisternig            Expires January 14, 2009               [Page 41]


Internet-Draft A lightweight security extension for ULE       July 2008


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.


























Noisternig            Expires January 14, 2009               [Page 42]