diff options
| author | Christian Pointner <equinox@anytun.org> | 2009-12-05 13:33:22 +0000 |
|---|---|---|
| committer | Christian Pointner <equinox@anytun.org> | 2009-12-05 13:33:22 +0000 |
| commit | cf0c74e107c5b56fd3f0b425e1e103f4bb47c1ff (patch) | |
| tree | 3f65b33b11bf302b9c7da533ba8541b5cfc58ced /papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.txt | |
| parent | updated ChangeLog for release (diff) | |
removed common stuff (moved to repo anytun-common)
Diffstat (limited to 'papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.txt')
| -rw-r--r-- | papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.txt | 1456 |
1 files changed, 0 insertions, 1456 deletions
diff --git a/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.txt b/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.txt deleted file mode 100644 index a636f71..0000000 --- a/papers/draft-gsenger-pointner-secure-anycast-tunneling-protocol-01.txt +++ /dev/null @@ -1,1456 +0,0 @@ - - - -Network Working Group O. Gsenger -Internet-Draft C. Pointner -Expires: October 3, 2009 April 2009 - - - secure anycast tunneling protocol (SATP) - draft-gsenger-pointner-secure-anycast-tunneling-protocol-01 - -Status of this Memo - - 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/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on October 3, 2009. - - - - - - - - - - - - - - - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 1] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - -Abstract - - The secure anycast tunneling protocol (SATP) defines a protocol used - for communication between any combination of unicast and anycast - tunnel endpoints. It allows tunneling of every ETHER TYPE protocol - (ethernet, ip ...). SATP directly includes cryptography and message - authentication based on the methods used by the Secure Real-time - Transport Protocol(SRTP) [RFC3711]. It can be used as an encrypted - alternative to IP Encapsulation within IP [RFC2003] and Generic - Routing Encapsulation (GRE) [RFC2784]. Both anycast receivers and - senders are supported. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 2] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 - 2. Motivation and usage scenarios . . . . . . . . . . . . . . . . 5 - 2.1. Usage scenarions . . . . . . . . . . . . . . . . . . . . . 5 - 2.1.1. Tunneling from unicast hosts over anycast routers - to other unicast hosts . . . . . . . . . . . . . . . . 5 - 2.1.2. Tunneling from unicast hosts to anycast networks . . . 6 - 2.1.3. Redundant tunnel connection of 2 networks . . . . . . 6 - 2.2. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 7 - 3. Using SATP on top of IP . . . . . . . . . . . . . . . . . . . 9 - 3.1. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 9 - 3.2. ICMP messages . . . . . . . . . . . . . . . . . . . . . . 9 - 4. Protocol specification . . . . . . . . . . . . . . . . . . . . 10 - 4.1. Header format . . . . . . . . . . . . . . . . . . . . . . 10 - 4.2. sequence number . . . . . . . . . . . . . . . . . . . . . 10 - 4.3. sender ID . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.4. MUX . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.5. payload type . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.6. payload . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.7. padding (OPTIONAL) . . . . . . . . . . . . . . . . . . . . 11 - 4.8. padding count (OPTIONAL) . . . . . . . . . . . . . . . . . 11 - 4.9. authentication tag (RECOMMENDED) . . . . . . . . . . . . . 11 - 5. Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 5.1. Basic Concepts . . . . . . . . . . . . . . . . . . . . . . 12 - 5.1.1. Cryptographic Contexts . . . . . . . . . . . . . . . . 12 - 5.1.2. SATP Packet Processing . . . . . . . . . . . . . . . . 13 - 5.1.3. Key derivation . . . . . . . . . . . . . . . . . . . . 15 - 5.2. Predefined Transforms . . . . . . . . . . . . . . . . . . 16 - 5.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 16 - 5.2.2. Authentication and Integrity . . . . . . . . . . . . . 18 - 5.2.3. Key Derivation Pseudo Random Functions . . . . . . . . 18 - 5.3. Adding SATP Transforms . . . . . . . . . . . . . . . . . . 19 - 6. Key Managment and Anycast Synchronization Considerations . . . 20 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 - 7.1. Replay protection . . . . . . . . . . . . . . . . . . . . 21 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 - 9.2. Informational References . . . . . . . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 - Intellectual Property and Copyright Statements . . . . . . . . . . 26 - - - - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 3] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - -1. Introduction - - SATP is a mixture of a generic encapsulation protocol like GRE - [RFC2784] and a secure tunneling protocol as IPsec [RFC2401] in - tunnel mode. It can be used to build redundant virtual private - network (VPN) connections. It supports peer-to-peer tunnels, where - tunnel endpoints can be any combination of unicast, multicast or - anycast hosts, so it defines a Host Anycast Service [RFC1546]. - Encryption is done per packet, so the protocol is robust against - packet loss and routing changes. To reduce header overhead, - encryption techniques similar to SRTP [RFC3711] are being used. - -1.1. Notational Conventions - - The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC2119 [RFC2119]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 4] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - -2. Motivation and usage scenarios - - This section gives an overview of possible usage scenarios. Please - note that the protocols used in the figures are only examples and - that SATP itself does not care about either transport protocols or - encapsulated protocols. Routing is not done by SATP and each - implemetation MAY choose it's own way of doing this task (e.g. using - functions provided by the operating system). SATP is used only to - encapsulate and encrypt data. - -2.1. Usage scenarions - -2.1.1. Tunneling from unicast hosts over anycast routers to other - unicast hosts - - An example of SATP used to tunnel in a unicast client - anycast - server model - - --------- router ----------- - / \ - unicast ------+---------- router ------------+------ unicast - host \ / host - --------- router ----------- - - unicast | encrypted | anycast | encrypted | unicast - tunnel | communication | tunnel | communication | tunnel - endpoint | using SATP | endpoint | using SATP | endpoint - - Figure 1 - - In this scenario the payload is encapsuleted into a SATP packet by a - unicast host and gets transmitted to one of the anycast routers. - After transmisson the packet gets decapsulated by the router. This - router makes a routing descision based on the underlying protocol and - transmits a new SATP package to one or more unicast hosts depending - on this decision. - - - - - - - - - - - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 5] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - -2.1.2. Tunneling from unicast hosts to anycast networks - - An example of SATP used to encrypt data between a unicast host and - anycast networks - - -------Router -+---- DNS Server - / \ - / --- 6to4 Router - / - unicast -------+----------Router --+--- DNS Server - host \ \ - \ --- 6to4 Router - \ - -------Router -+---- DNS Server - \ - --- 6to4 Router - - unicast | encrypted | anycast | plaintext - tunnel | communication | tunnel | anycast - endpoint | using SATP | endpoint | services - - - Figure 2 - - When the unicast hosts wants to transmit data to one of the anycast - DNS servers, it encapsulates the data and sends a SATP packet to the - anycast address of the routers. The packet arrives at one of the - routers, gets decapsulated and is then forwarded to the DNS server. - This method can be used to tunnel between clients and networks - providing anycast services. It can also be used the other way to - virtually locate a unicast service within anycasted networks. - -2.1.3. Redundant tunnel connection of 2 networks - - An example of SATP used to connect 2 networks - - Router ----------- ---------------Router - / \ / \ - Network - Router ------------x Network - A \ / \ / B - Router ----------- ---------------Router - - | packets | packets | packets | - plaintext | get | take a | get | plaintext - packets | de/encrypted | random | de/encrypted | packets - |de/encapsulated| path |de/encapsulated| - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 6] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - - Figure 3 - - Network A has multiple routers which act as gateway/tunnel endpoints - to another network B. This way a redundant encrypted tunnel - connection between the two networks is built up. All tunnel - endpoints of network A share the same anycast address and all tunnel - endpoints of network B share another anycast address. When a packet - from network A is transmitted to network B, it first arrives on one - of network A's border routers. Which router is used is determined by - network A's internal routing. This router encapsulates the package - and sends it to the anycast address of network B's routers. After - arrival the SATP packet gets decapsulated and routed to its - destination within network B. - -2.2. Encapsulation - - SATP does not depend on the lower layer protocol. This section only - gives an example of how packets could look like. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 7] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - - Examples of SATP used with different lower layer and payload - protocols - - +------+-----+-------------------------------+ - | | | +----------------+-----+ | - | IPv6 | UDP | SATP | Ethernet 802.3 | ... | | - | | | +----------------+-----+ | - +------+-----+-------------------------------+ - - Tunneling of Ethernet over UDP/IPv6 - - +------+-----+---------------------------+ - | | | +------+-----+-----+ | - | IPv4 | UDP | SATP | IPv6 | UDP | RTP | | - | | | +------+-----+-----+ | - +------+-----+---------------------------+ - - Tunneling of IPv6 over UDP/IPv4 with RTP payload - - +------+-------------------------------+ - | | +----------------+-----+ | - | IPv6 | SATP | Ethernet 802.3 | ... | | - | | +----------------+-----+ | - +------+-------------------------------+ - - Tunneling of Ethernet over IPv6 - - +------+---------------------------+ - | | +------+-----+-----+ | - | IPv4 | SATP | IPv6 | UDP | RTP | | - | | +------+-----+-----+ | - +------+---------------------------+ - - Tunneling of IPv6 over IPv4 with RTP payload - - Figure 4 - - - - - - - - - - - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 8] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - -3. Using SATP on top of IP - -3.1. Fragmentation - - The only way of fully supporting fragmentation would be to - synchronise fragments between all anycast servers. This is - considered to be too much overhead, so there are two non-perfect - solutions for these problems. Either fragmentation HAS TO be - disabled or if not all fragments arrive at the same server the IP - datagramm HAS TO be discarded. As routing changes are not expected - to occur very frequently, the encapsulated protocol can do a - retransmission and all fragments will arrive at the new server. - - If the payload type is IP and the IP headers' Don't Fragment (DF) bit - is set, then the DF bit of the outer IP header HAS TO be set as well. - -3.2. ICMP messages - - ICMP messages MUST be relayed according to rfc2003 section 4 - [RFC2003]. This is needed for path MTU detection. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 9] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - -4. Protocol specification - -4.1. Header format - - Protocol Format - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | sequence number | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | sender ID | MUX | | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+ | - | | payload type | | | - | +-------------------------------+ | | - | | .... payload ... | | - | | +-------------------------------+ | - | | | padding (OPT) | pad count(OPT)| | - +#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+#+-+ - | : authentication tag (RECOMMENDED) : | - | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | - | | - +- Encrypted Portion Authenticated Portion ---+ - - Figure 5 - -4.2. sequence number - - The sequence number is a 32 bit unsigned integer in network byte - order. The starting point is signaled by the key exchange mechanism - and then value is then increased by 1 for every packet sent. After - the maximum value it starts over from 0. - -4.3. sender ID - - The sender ID is a 16 bit unsigned integer. It HAS TO be unique for - every sender sharing the same anycast address. - -4.4. MUX - - The MUX (multiplex) field is a 16 bit unsigned integer. It is used - to distinguish multiple tunnel connections. - -4.5. payload type - - The payload type field defines the payload protocol. ETHER TYPE - protocol numbers are used. See IANA assigned ethernet numbers [1] . - The values 0000-05DC are reserverd and MUST NOT be used. - - - -Gsenger & Pointner Expires October 3, 2009 [Page 10] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - - Some examples for protocol numbers - - HEX - 0000 Reserved - .... Reserved - 05DC Reserved - 0800 Internet IP (IPv4) - 6558 transparent ethernet bridging - 86DD IPv6 - - Figure 6 - -4.6. payload - - A packet of type payload type (e.g. an IP packet). - -4.7. padding (OPTIONAL) - - Padding of max 255 octets. None of the pre-defined encryption - transforms uses any padding; for these, the plaintext and encrypted - payload sizes match exactly. Transforms which may be added in future - (see Section 5.3) MUST define wheter they need padding or not and if - they need it they MUST define a proper padding format. If the - padding count field is present, the padding count field MUST be set - to the padding length. - -4.8. padding count (OPTIONAL) - - The number of octets of the padding field. This field is optional. - Its presence is signaled by the key management and not by this - protocol. If this field isn't present, the padding field MUST NOT be - present as well. - -4.9. authentication tag (RECOMMENDED) - - The authentication tag is RECOMMENDED and of configurable length. It - contains a cryptographic checksum of the sender ID, sequence number - and the encrypted portion. On transmitter side encryption HAS TO be - done before calculating the authentication tag. A receiver HAS TO - calculate the authentication tag before decrypting the encrypted - portion. - - - - - - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 11] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - -5. Cryptography - - As mentioned earlier the cryptography of SATP is based on SRTP - [RFC3711]. For that reason we recommend to read this document as - well (especially chapter 7 Rationale). However some modifications - were made in order to fit the changed conditions of SATP. The - following section describes the whole cryptography of SATP. - -5.1. Basic Concepts - - In order to cope with anycast and packet loss it is important to be - able to process one packet on its own without the need for packets - from the past as an additional information source. Therefore SATP as - well as SRTP [RFC3711] defines a so called cryptographic context. - This context consits of all information which is needed to process a - single SATP packet and is divided into packet specific parameters and - global parameters. The packet specific parameters can be found in - the protocol header and global parameters have to be generated by the - key exchange mechanism external to SATP (see Section 6). For anycast - sender the global parameters have to be synchronized between all - hosts which share the same anycast address. The packet specific - parameters MUST NOT be synchronized. - SATP uses two types of keys: master keys and session keys. A session - key is meant to be used for a cryptographic transform (encrytion or - message authentication) for one packet. The master keys are used to - derive packet-specific session keys in a cryptographical secure way. - -5.1.1. Cryptographic Contexts - -5.1.1.1. Global Parameters - - As mentioned above global parameters HAVE TO either be provided by - the key exchange mechanism or configured manually. - - o a master key(s) which MUST be random and kept secret. - - o a master salt which MUST be random and MAY be public (RECOMMENDED - to be kept secret as well). - - o a role specifier used by the key derivation to determine which - session keys to generate for outbound or inbound traffic. - - o identifier for the key derivation pseudo random function. - - o identifier for the encryption algorithm (i.e. cipher and its mode - of operation). - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 12] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - - o if used an identifier for the authentication algorithm. - - o transform specific parameters such as key lengths, see - Section 5.2. - - o if used the length of the authentication tag which should be - truncated to the packet. - - o an indicator which specifies if padding is needed or not (presence - of padding count field). - - o a replay list for each sender (see Section 5.1.1.3), maintained by - the receiver which contains the sequence numbers of received and - authenticated packets, this lists may be implemented as a sliding - window. - - o a [ From , To ] value pair which specifies the lifetime of a - master key (including the range endpoints), expressed in terms of - a pair of 32-bit sequence numbers. - -5.1.1.2. Packet-Specific Parameters - - o the sequence number - - o the sender id - - o the mux value - -5.1.1.3. Mapping SATP packets to Cryptographic Contexts - - A cryptographic contexts SHALL be uniquely identifed by the tuple - context identifier: - - context id = [ source address , source port ] - - In order to cope with anycast sender and replay protection there HAS - TO be more than one replay list per context. Each replay list inside - a cryptographic context SHALL be uniquely identified by the sender - id. - -5.1.2. SATP Packet Processing - - Before any SATP packet can be processed a cryptographic context HAS - TO be initialized by the key management mechanism. After that a SATP - sender SHALL do the following to create a SATP packet: - - 1. Determine the next sequence number to use. - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 13] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - - 2. Determine the crypotgraphic context as described in - Section 5.1.1.3. - - 3. Determine the master key and master salt for the packets sequence - number. - - 4. Compute all session keys and session salts which are needed by - the encryption transform using the key derivation pseudo random - function. - - 5. Encrypt the payload type field concatenated with the payload to - produce the encrypted portion of the packet using the encryption - algorithm defined by the cryptographic context. - - 6. Fill in sender id, mux and sequence number fields. - - 7. If needed compute the session authentication key using the key - derivation pseudo random function. - - 8. Generate the authentication tag over the authenticated portion - using the authentication algorithm defined by the cryptographic - context and append it to the packet. - - On receiver side the packet SHALL be processed as follows: - - 1. Determine the crypotgraphic context as described in - Section 5.1.1.3. - - 2. Determine the master key and master salt for the packets - sequence number. - - 3. Check if the packet was replayed using the replay list for the - packets sender id. - - 4. If needed compute the session authentication key using the key - derivation pseudo random function. - - 5. Generate the authentication tag over the authenticated portion - using the authentication algorithm defined by the crpyptographic - context and compare it with the tag appended to the received - packet. If it is equal remove the tag and move on. If it is - not equal drop the packet. - - 6. Store the sequence number in the replay list. - - 7. Compute all session keys and session salts which are needed by - the encryption transform using the key derivation pseudo random - function. - - - -Gsenger & Pointner Expires October 3, 2009 [Page 14] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - - 8. Decrypt the encrypted portion using the encryption algorithm - defined by the cryptographic context. - - 9. Check if the payload type is supported by this tunnel endpoint - and discard the packet in case it isn't supported. - - 10. Remove all fields beside the payload itself from the packet. - -5.1.3. Key derivation - - Any encryption or message authentication transform which is used - (predefined or newly introduced according to Section 5.3) MUST obtain - its secret values (keys and salts) using the SATP key derivation. - After the key exchange mechanism has signaled all needed parameters - (i.e. master key and salt) no additional communiction between sender - and receiver is needed until the next rekeying takes place. To - achieve this the key derivation uses an pseudo random function seeded - by the master key, master salt, the packets sequence number and a - label (identifier for the key to compute). - - SATP key derivation - - packet sequence nummber ----+ - | - V - +------------+ master +------------+ - | | key | |--> session encryption key - | ext. key |------->| key | - | management | | |--> session encryption salt - | mechanism |------->| derivation | - | | master | |--> session authentication key - +------------+ salt +------------+ - - Figure 7 - - SRTP [RFC3711] defines a pseudo random function as follows: - Let m and n be positive integers. A pseudo-random function family is - a set of keyed functions {PRF_n(k,x)} such that for the (secret) - random key k, given m-bit x, PRF_n(k,x) is an n-bit string, - computationally indistinguishable from random n-bit strings. - - For SATP key generation a pseudo random function with at least m = - 128 MUST be used. A predefined transform can be found in - Section 5.2.3. The input x of the PRF SHOULD be calculated as - follows: - - 1. Let key_id = label || sequence_number, with label defined as - below. - - - -Gsenger & Pointner Expires October 3, 2009 [Page 15] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - - 2. Let x = key_id XOR master_salt, where key_id and master_salt are - aligend so that their least significant bits agree (right- - alignment). - - For each key derived by the key derivation there MUST exist a unique - label, a 32-bit constant. In order to increase security SATP uses - different session keys for inbound and outbound traffic. The role - specifier from the cryptographic context is used to determine which - session keys to use for inbound and outbound packets. The labels can - be computed by calculateing the SHA1 hash over an increasing label- - index. The label value are the 32 leftmost bits of this hash value. - We currently define 6 labels (label-index from 1 to 6) future - extensions may use labels with an index from 7 upwards. - - +--------------------+-------+-------------+------------+ - | key type | role | label-index | label | - +--------------------+-------+-------------+------------+ - | encryption key | left | 1 | 0x356A192B | - | | | | | - | encryption key | right | 2 | 0xDA4B9237 | - | | | | | - | encryption salt | left | 3 | 0x77DE68DA | - | | | | | - | encryption salt | right | 4 | 0x1B645389 | - | | | | | - | authentication key | left | 5 | 0xAC3478D6 | - | | | | | - | authentication key | right | 6 | 0xC1DFD96E | - +--------------------+-------+-------------+------------+ - - Key Derivation Labels - - The role parameter specifies which label should be used for outbound - packets. This means a endpoint with role left MUST use the labels - marked with left for outgoing packets and expects inbound packets to - be encrypted/authenticated using the labels marked with right. - -5.2. Predefined Transforms - - While SATP as well as SRTP allows the use of various encryption and - message authentication algorithms interoperable implementations MUST - support at least the following transforms. To add additional - transforms see Section 5.3. - -5.2.1. Encryption - - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 16] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - -5.2.1.1. NULL Encryption - - If confidendtiality of the SATP packet is not an issue the null - encryption transform can be used to increase performance. This - transform just copies the plaintext input into the ciphertext output - wihtout any padding. The identifier for that transfrom SHOULD be - NULL and it don't needs any transform specific parameters. It also - doesn't need any key or salt values computed by the key derivation. - -5.2.1.2. AES in Counter Mode - - The following describes how to use AES in counter mode for SATP - encryption. The identifier for that transform SHOULD be AES-CTR- - <key_length> or just AES-CTR in which case the key length defaults to - 128 bits. Beside the key length there are no additional transfrom - specific parameters. This transform needs a key of length - <key_length> and a 112 bit salt. These values can be generated using - the key derivation pseudo random function as follows: - - session_key = PRF_<key_length>(master_key, x) - session_salt = PRF_112(master_key, x) - with PRF and x defined as in Section 5.1.3. - - Basically AES in counter mode generates a pseudo random keystream - seeded by the session key, session salt as well as the sequence - number, sender id and mux value of the packet and encrypts a single - SATP packet using this stream. The encryption process consits of the - generation of that keystream and then bitwise exclusive-oring it onto - the packets payload. If the packet length doesn't fit a multiple of - 128 bits the remaining bits (least significant) of the keystream are - simple ingored. Therefore this transform does not need any padding. - Decryption of the packet can be achieved by generating the same - keystream and exclusive-oring it onto the encrypted portion. - -5.2.1.2.1. Keystream Generation - - In principle AES in counter mode consists of encrypting an - incrementing integer. However the starting point of the integer - value has to be randomized to get a good pseudo random key stream. A - keystream consits of several keystream segements with a size of 128 - bits (AES blocksize). Each segement can be computed by applying AES - with key k on the block CTR. The whole keystream is a concatination - of all its successive segements. Therefore a keystream looks as - follows: - - AES(session_key, CTR) || AES(session_key, CTR + 1 mod 2^128) || - AES(session_key, CTR + 2 mod 2^128) ... - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 17] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - - where the 128 bit value CTR is defined as follows: - - CTR = (session_salt * 2^16) XOR (mux * 2^80) XOR (sender_id * 2^64) - XOR (sequence_number * 2^16) - - where each of the four terms are padded with as many leading zeros to - form a 128 bit value. - - Mind that the 16 least siginificant bits of CTR are zero. These bits - are used for the counter. Therefore the number of blocks generated - for one packet MUST NOT exceed 2^16 to avoid keystream reuse. This - means that the packet length MUST NOT exceed 2^16 * 128 bits = 2^23 - bits to ensure the security of the encryption. - -5.2.2. Authentication and Integrity - - It is RECOMMENDED to use an authentication tag and if it is used it - should be processed as follows. The sender generates the tag over - the authenticated portion truncates it to the left-most (most - significant) bits to fit the authentication tag length signaled by - the key exchange mechanism. After that it simple appends the tag to - the packet. The receiver computes the tag in the same way as the - sender and compares if with the received tag. If they don't match - the packet HAS TO be discarded and the incident SHOULD be logged. - -5.2.2.1. HMAC-SHA1 - - This transform uses HMAC-SHA1 (as described in [RFC2104]) as message - authentication algorithm. The identifier for the transfrom SHOULD be - SHA1 and it don't needs any transform specific parameters. The key - should be derived using the key derivation pseudo random function: - - session_auth_key = PRF_20(master_key, x) - with PRF and x defined as in Section 5.1.3 - -5.2.3. Key Derivation Pseudo Random Functions - -5.2.3.1. AES in Counter Mode - - Section 5.1.3 defines a pseudo random function which SHOULD be used - to derive session keys and salts. This describes the use of AES in - counter mode as PRF. The identifier for this PRF SHOULD be AES-CTR- - <key_length> or just AES-CTR in which case the key length defaults to - 128 bits. Beside the key length there are no additional transform - specific parameters. This transform needs a master key of length - key_length and a 112 bit master salt. The pseudo random string - consists of several segements with a size of 128 bits (AES - blocksize). The whole string can be computed as follows: - - - -Gsenger & Pointner Expires October 3, 2009 [Page 18] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - - AES(master_key, CTR) || AES(master_key, CTR + 1 mod 2^128) || - AES(master_key, CTR + 2 mod 2^128) ... - - where the 128 bit value CTR is defined as x * 2^16, with x defined as - in Section 5.1.3. - - This pseudo random function can produce pseudo random strings up to a - length of 2^23 bits. If the requested output length n does not fit - multiples of 128 bits the output SHOULD be truncated to the n first - (left-most) bits. Therefore there are n/128, rounded up, - applications of AES needed to produce the output string. - -5.3. Adding SATP Transforms - - If a new transform is to be added to SATP a standard track RFC MUST - be written to define the usage of the new transform. Any overlap - between the new RFC and this document SHOULD be avoided but it MAY be - needed to update some of the information in this document. For - example new parameters MAY be added to the cryptographic context or - there MAY be additional steps in SATP packet processing. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 19] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - -6. Key Managment and Anycast Synchronization Considerations - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 20] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - -7. Security Considerations - - As the cryptography of SATP is based on SRTP [RFC3711], it basically - shares the same security issues. This section will only discuss some - small changes. Please read SRTP RFC3711 section 9 [RFC3711] for - details. - -7.1. Replay protection - - Replay protection is done by a replay list. Every anycast receiver - has its own replay list, which SHOULDN'T be syncronised because of - massive overhead. This leads to an additional possible attack. An - attacker is able to replay a captured packet once to every anycast - receiver. This attack is considered be very unlikely because - multiple attack hosts in different locations are needed to reach - seperate anycast receivers and the number of replays is limited to - count of receivers - 1. Such replays might also happen because of - routing problems, so a payload protocol HAS TO be robust against a - small number of duplicated packages. The window size and position - HAS TO be syncronised between multiple anycast receivers to limit - this attack. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 21] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - -8. IANA Considerations - - The protocol is intended to be used on top of IP or on top of UDP (to - be compatible with NAT routers), so UDP and IP protocol numbers have - to be assiged by IANA. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 22] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - -9. References - -9.1. Normative References - - [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. - Norrman, "The Secure Real-time Transport Protocol (SRTP)", - RFC 3711, March 2004. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, - October 1996. - - [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, - February 1997. - -9.2. Informational References - - [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. - Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, - March 2000. - - [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. - - [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host - Anycasting Service", RFC 1546, November 1993. - - - - - - - - - - - - - - - - - - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 23] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - -URIs - - [1] <http://www.iana.org/assignments/ethernet-numbers> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 24] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - -Authors' Addresses - - Othmar Gsenger - Puerstingerstr 32 - Saalfelden 5760 - AT - - Phone: - Email: satp@gsenger.com - URI: http://www.gsenger.com/satp/ - - - Christian Pointner - Wielandgasse 19 - Graz 8010 - AT - - Phone: - Email: equinox@anytun.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 25] - -Internet-Draft secure anycast tunneling protocol (SATP) April 2009 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2009). - - 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. - - 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. - - -Intellectual Property - - 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. - - - - - - - - - - - -Gsenger & Pointner Expires October 3, 2009 [Page 26] - |