HIP Working Group P. Urien Internet Draft Telecom ParisTech Intended status: Informational December 12, 2008 Expires: June 12, 2009 HIP support for RFID draft-urien-hip-tag-01.txt 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 June, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). All rights reserved. Urien Expires June 2009 [Page 1] HIP support for RFIDs December 2008 Abstract This document describes an architecture based on the Host Identity Protocol (HIP), for active tags, i.e. RFIDs that include tamper resistant computing resources, as specified for example in the ISO 14443 or 15693 standards. HIP-Tags never expose their identity in clear text, but hide this value (typically an EPC-Code) by a particular equation (f) that can be only solved by a dedicated entity, referred as the portal. HIP exchanges occurred between HIP- Tags and portals; they are shuttled by IP packets, through the Internet cloud. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Urien Expires June 2009 [Page 2] HIP support for RFIDs December 2008 Table of Contents Copyright Notice................................................... 1 Abstract........................................................... 2 Conventions used in this document.................................. 2 Table of Contents.................................................. 3 1 Overview......................................................... 4 1.1 Passive and Active tags..................................... 4 1.1 About the Internet Of Things (IoT).......................... 4 1.2 HIP-Tags.................................................... 5 2. Basic Exchange.................................................. 7 2.1 I1-T........................................................ 7 2.2 R1-T........................................................ 8 2.3 I2-T........................................................ 8 2.4 R2-T........................................................ 8 3. Formats......................................................... 9 3.1 Payload..................................................... 9 3.2 Packets types.............................................. 10 3.3 Summary of HIP parameters.................................. 11 3.4 R-T........................................................ 11 3.5 HIP-T-Transform............................................ 12 3.6 F-T........................................................ 12 3.7 Signature-T................................................ 13 3.8 ESP-Transform.............................................. 13 3.9 ESP-Info................................................... 13 4. BEX Example.................................................... 14 4.1 Message I1-T............................................... 14 4.2 Message I2-T............................................... 14 4.3 I2-T....................................................... 15 4.4 R2-T....................................................... 16 5. HIP-T-Transforms definition.................................... 16 5.1 Type 0x0001................................................ 16 5.1.1 F-T computing (f function) .......................... 16 5.1.2 K-Auth-Key computing (g function) ................... 16 5.1.3 Signature-T computing ............................... 17 6. Security Considerations........................................ 18 7. IANA Considerations............................................ 18 8 References...................................................... 18 8.1 Normative References....................................... 18 8.2 Informative References..................................... 18 Author's Addresses................................................ 18 Intellectual Property Statement................................... 19 Disclaimer of Validity............................................ 19 Copyright Statement............................................... 19 Acknowledgment.................................................... 19 Urien Expires June 2009 [Page 3] HIP support for RFIDs December 2008 1 Overview 1.1 Passive and Active tags An RFID is a slice of silicon whose area is about 1 mm2 for components used as cheap electronic tags, and around 25 mm2 for chips like contact-less smart cards inserted in passports and mobile phones. We divide RFIDs in two classes, the first includes devices that embed CPU and memories (RAM, ROM, E2PROM) such as contact-less smart cards, the second comprises electronic chips based on cabled logic circuits. There are multiple standards relative to RFIDs. The ISO 14443 standard introduces components dealing with the 13,56Mhz frequency that embed a CPU and consume about 10mW; data throughput is about 100 Kbits/s and the maximum working distance (from the reader) is around 10cm. The ISO 15693 standard also uses the same 13,56 MHz frequency, but enables working distances as high as one meter, with a data throughput of a few Kbits/s. The ISO 18000 standard defines parameters for air interface communications associated with frequency such as 135 KHz, 13,56 MHz, 2.45 GHz, 5.8 GHz, 860 to 960 MHz and 433 MHz. The ISO 18000-6 standard uses the 860-960 MHz range and is the basis for the Class-1 Generation-2 UHF RFID, introduced by the EPCglobal [EPCGLOBAL] consortium. 1.1 About the Internet Of Things (IoT) The term Internet of Thing (IoT) was invented by the MIT Auto-ID Center, in 2001, and refers to an architecture that comprises four levels, - Passive tags, such as Class-1 Generation-2 UHF RFIDs, introduced by the EPC Global consortium and operating in the 860-960 MHz range. - Readers plugged to a local (computing) system, which read the Electronic Product Code [EPC]. - A local system, offering IP connectivity, which collects information pointed by the EPC thanks to a protocol called Object Naming Service (ONS) - EPCIS (EPC Information Services) servers, which process incoming ONS requests and returns PML (Physical Markup Language) files [PML], e.g. XML documents that carry meaningful information linked to tags. Urien Expires June 2009 [Page 4] HIP support for RFIDs December 2008 1.2 HIP-Tags We suggest embedding a modified version of HIP stack in active tags, named HIP-Tags. We believe that such devices would not support an IP stack, but should be rather identity oriented, i.e. will use readers IP resources in order to unveil their EPC-Code only to trusted entities (called portals in our propose architecture). Privacy, e.g. identity protection seems a key prerequisite [SEC] before the effective massive deployment of these devices. PORTAL READER TAG +-----------------------+ ! ! +-----------+ ! +-----+ ! ! +-------+ ! ! +---------+ + HIP + !<========================>! + HIP + ! ! + IDENTITY+ +-----+ ! +-------------------+ ! +-------+ ! ! + SOLVER + [HAT] !<=>! [HAT] ! ! | ! ! +---------+ +-----+ ! ! +------+-------+ ! ! +-------+ ! ! + + ! ! + + RFID + ! ! + RFID + ! ! EPC-Code + IP + !<=>! + IP + Radio + !<>! + Radio + ! ! + + ! ! + + Ptcol + ! ! + Ptcol + ! ! +-----+ ! ! +------+-------+ ! ! +-------+ ! ! ! ! ! ! ! +----------+------------+ +-------------------+ +-----------+ ! V TO EPC GLOBAL SERVICES Figure 1. HIP-Tag Architecture The functional HIP-TAG architecture includes three logical entities, - HIP tags. HIP is transported by IP packets. HIP tags support a modified version of this protocol but don't include IP resources. - RFID readers. They provide IP connectivity and communicate with tags through radio link either defined by EPC Global or ISO standards. The IP layer transports HIP messages between tags and other HIP entities. According to HIP, an SPI (Security Parameter Index) associated to an IPSEC tunnel MAY be used by the IP host (e.g. a reader) in order to route HIP packets to/from the right software identity. - HAT, HIP Address translator. HIP messages MAY be encapsulated by transport protocols such as UDP in order to facilitate HIP support in existing software and networking architectures. Urien Expires June 2009 [Page 5] HIP support for RFIDs December 2008 - PORTAL entity. This device manages a set of readers; it is an HIP entity that includes a full IP stack. Communications between portal and tags logically work as peer to peer HIP exchanges. RFID identity (HIT) is hidden and appears as a pseudo random value; within the portal a software block called the IDENTITY SOLVER resolves an equation f, whose solution is an EPC Code. The portal accesses to EPCIS services; when required privacy may be enforced by legacy protocol such as SSL or IPSEC. - The portal maintains a table linking HIT and EPC-Code. It acts as a router for that purpose it MUST provide an identity resolution mechanism, i.e. a relation between HIT and EPC-Code. Urien Expires June 2009 [Page 6] HIP support for RFIDs December 2008 2. Basic Exchange The HIP-Tags basic exchange (T-BEX) is derived from the "classical" BEX exchange, introduced in [HIP]. It is a four ways handshake illustrated by figure 2. TAG PORTAL --+-- ---+--- ! ! ! I1-T ! ! HIT-I HIT-R ! ! ----------------------------------------------------> ! ! ! ! ! ! R1-T ! ! HIT-I HIT-R R-T(r1) HIP-T-Transforms ! ! [ESP-Transforms] ! ! <---------------------------------------------------- ! ! ! ! ! ! I2-T ! ! HIT-I HIT-R HIP-T-Transform [ESP-Transform] R-T(r2) ! ! F-T=f(r1, r2, EPC-Code) [ESP-Info] Signature-T ! ! ----------------------------------------------------> ! ! ! ! ! ! R2-T ! ! HIT-I HIT-R [ESP-Info] Signature-T ! ! <---------------------------------------------------- ! ! ! ! ! ! Optional ESP Dialog ! ! <---------------------------------------------------> ! ! ! ! ! Figure 2. HIP-Tags Basic Exchange (T-BEX) 2.1 I1-T When a reader detects a tag, it realizes all low level operations in order to set up a radio communication link. The HIP tag sends the I1-T packet (I suffix meaning initiator), in which HIT-I is a true random value internally generated by HIP-Tag. If the tag doesn't known the portal HIT it sets the HIT-R value to zero; in that case the reader MAY modify this field in order to identify the appropriate entity. Urien Expires June 2009 [Page 7] HIP support for RFIDs December 2008 2.2 R1-T The portal produces the R1-T (R suffix meaning responder) packet, which includes a nonce r1 and optional parameters. These fields indicate a list of supported authentication schemes (HIP-T- TRANSFORMs) and a list of ESP-TRANSFORMs, i.e. secure channels that could be opened with the tag. 2.3 I2-T The HIP-Tag builds the I2-T message, which contains - The selected HIP-T-TRANSFORM (the current authentication scheme). - An optional ESP-TRANSFORM (a class of secure channel between tag and portal). - A nonce r2, included in the R-T attribute. - An equation f(r1, r2, EPC-Code), whose solution, according to the selected HIP-T-TRANSFORM, unveils the EPC-Code value. - An optional ESP-Info attribute that gives information about the secure (ESP) channel, and which includes the SPI-I value. - A signature (Signature-T), which works a KI-Auth-key deduced from r1, r2 and the hidden EPC-CODE value. KI-Auth-key = g(r1, r2, EPC-Code) 2.4 R2-T The fourth and last R2-T packet is optional. It includes - A signature (Signature-T) computed with the KI-Auth-key deduced from r1, r2 and the hidden EPC-CODE value. KI-Auth-key = g(r1, r2, EPC-Code) - An optional ESP-Info attribute that gives information about the secure (ESP) channel, and which includes the SPI-R value. Urien Expires June 2009 [Page 8] HIP support for RFIDs December 2008 3. Formats 3.1 Payload The payload format is imported from the [HIP] specification. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Header Length |0| Packet Type | VER. | RES.|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Controls | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender's Host Identity Tag (HIT) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver's Host Identity Tag (HIT) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / HIP Parameters / / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header : normal value is decimal 59, IPPROTO_NONE. Header Length: the length of the HIP Header and HIP parameters in 8 bytes units, excluding the first 8 bytes Packet Type: Detailed in section 4.2 VER: 0001 RES: 000 Checksum: This checksum covers the source and destination addresses in the IP header. HIP-Tags deliver HIP packets with the null value for the checksum field. Controls: this field is reserved for future use (RFU) Sender's Host Identity Tag: 16 bytes HIT Receiver's Host Identity Tag: 16 bytes HIT HIP Parameters: a list of attributes encoded in the TLV format Urien Expires June 2009 [Page 9] HIP support for RFIDs December 2008 3.2 Packets types +-----------------+-------------------------------------------+ | Packet type | Packet name | +-----------------+-------------------------------------------+ | 0x40 | I1-T - The HIP-Tag Initiator Packet | | | | | 0x41 | R1-T - The HIP-Tag Responder Packet | | | | | 0x42 | I2-T - The Second HIP-Tag Initiator Packet| | | | | 0x43 | R2-T - The Second HIP-Tag Responder Packet| | | | +-----------------+-------------------------------------------+ Urien Expires June 2009 [Page 10] HIP support for RFIDs December 2008 3.3 Summary of HIP parameters +----------------------+-------+----------+-----------------------+ | TLV | Type | Length | Data | +----------------------+-------+----------+-----------------------+ | R-T | 0x400 | variable | Random value r1 or r2 | | | | | | | HIP-T-TRANSFORM | 0x402 | variable | HIP-Tag transform | | | | | | | F-T | 0x404 | variable | f function value | | | | | | | Signature-T | 0x406 | variable | Signature | | | | | | | ESP-Transform | 0x408 | variable | ESP transforms | | | | | | | ESP-Info | 0x40A | variable | ESP parameters | | | | | | +----------------------+-------+----------+-----------------------+ 3.4 R-T 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding-Length | value / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / value | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x400 Length total length in bytes Value random value Padding-Length padding length in bytes Padding padding bytes Urien Expires June 2009 [Page 11] HIP support for RFIDs December 2008 3.5 HIP-T-Transform 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding-Length | Suite-ID#1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Length-of-Suite-ID#1 | value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / value | Suite-ID#2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x402 Length Total length Padding-Length Number of padding bytes Suite-ID Defines the HIP Cipher Suite to be used Length-of-Suite-ID Defines the length of optional data Padding Padding bytes 3.6 F-T 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding-Length | value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x404 Length total length, in bytes Padding-Length padding length in bytes Value f value Padding padding bytes Urien Expires June 2009 [Page 12] HIP support for RFIDs December 2008 3.7 Signature-T 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding-Length | Signature / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x406 Length total length, in bytes Padding-Length padding length, in bytes Value Signature value Padding padding bytes A signature works with the K-Auth-Key and is computed over the whole HIP message, with the checksum field set to a null value. 3.8 ESP-Transform To be defined 3.9 ESP-Info To be defined Urien Expires June 2009 [Page 13] HIP support for RFIDs December 2008 4. BEX Example 4.1 Message I1-T Next Header: 0x3B Header Length: 0x4 Packet Type: 0x40 Version: 0x1 Reserved: 0x1 Control: 0x0 Checksum: 0xabcd Sender's HIT (Tag) : 0x0123456789ABCDEF 0123456789ABCDEF Receiver's HIT (Portal) : 0x0000000000000000 0000000000000000 The checksum is computed by portal and reader according to rules specified in [HIP]; it covers the source and destination IP addresses. 4.2 Message I2-T Next Header: 0x3B Header Length: 0xB Packet Type: 0x41 Version: 0x1 Reserved: 0x1 Control: 0x0 Checksum: 0xabcd Sender's HIT (Portal) 0xA5A5A5A5A5A5A5A5 5A5A5A5A5A5A5A5A Receiver's HIT (Tag) 0x0123456789ABCDEF 0123456789ABCDEF R-T 0x040000280002rrrr rrrrrrrrrrrrrrrr rrrrrrrrrrrrrrrr rrrrrrrrrrrrrrrr rrrrrrrrrrrrpppp HIP-T-Transforms 0x0402001000020001 000000020000pppp r1 is a 128 bits value Transforms 1, 2 are supported by the reader. Urien Expires June 2009 [Page 14] HIP support for RFIDs December 2008 4.3 I2-T Next Header: 0x3B Header Length: 0x14 Packet Type: 0x42 Version: 0x1 Reserved: 0x1 Control: 0x0 Checksum: 0xabcd Sender's HIT (Tag) : 0x0123456789ABCDEF 0123456789ABCDEF Sender's HIT (Portal) : 0xA5A5A5A5A5A5A5A5 5A5A5A5A5A5A5A5A HIP-T-Transform 0x0402001000060001 0000pppppppppppp R-T 0x040000280002rrrr rrrrrrrrrrrrrrrr rrrrrrrrrrrrrrrr rrrrrrrrrrrrrrrr rrrrrrrrrrrrpppp F-T 0x040400280002ffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffpppp Signature-T 0x040600040006ssss ssssssssssssssss ssssssssssssssss sssspppppppppppp The tag selects the HIP-Transform number one. It produces an r2 nonce and computes a f value. It appends a 20 bytes signature. Urien Expires June 2009 [Page 15] HIP support for RFIDs December 2008 4.4 R2-T Next Header: 0x3B Header Length: 0x8 Packet Type: 0x40 Version: 0x1 Reserved: 0x1 Control: 0x0 Checksum: 0xabcd Sender's HIT (Tag) : 0x0123456789ABCDEF 0123456789ABCDEF Sender's HIT (Portal) : 0xA5A5A5A5A5A5A5A5 5A5A5A5A5A5A5A5A Signature-T 0x040600040006ssss ssssssssssssssss ssssssssssssssss sssspppppppppppp Reader ends the BEX-T. 5. HIP-T-Transforms definition 5.1 Type 0x0001 5.1.1 F-T computing (f function) The F-T function produces a 20 bytes result, according to the relation: K = HMAC-SHA1(r1 | r2, EPC-Code) Y = f(r1, r2, EPC-Code) = HMAC-SHA1(K, CT1 | "Type 0001 key") Where: - SHA1 is the SHA1 digest function - EPC-Code is the tag identity - HMAC-SHA1 is the keyed MAC algorithm based on the SHA1 digest procedure. - CT1 is a 32 bits string, whose value is equal to 0x00000001 - r1 and r2 are the two random values exchanged by the BEX 5.1.2 K-Auth-Key computing (g function) The K-Auth-Key is computing according to the relation: Urien Expires June 2009 [Page 16] HIP support for RFIDs December 2008 K = HMAC-SHA1(r1 | r2, EPC-Code) Y = HMAC-SHA1(K, CT2 | "Type 0001 key") Where: - SHA1 is the SHA1 digest function - EPC-Code is the tag identity - HMAC-SHA1 is the keyed MAC algorithm based on the SHA1 digest procedure. - CT2 is a 32 bits string, whose value is equal to 0x00000010 - r1 and r2 are the two random values exchanged by the BEX 5.1.3 Signature-T computing The HMAC-SHA1 function is used with the K-Auth-Key secret value: Signature-T(HIT-T packet) = HMAC-SHA1(K-Auth-Key, HIP-T packet) Urien Expires June 2009 [Page 17] HIP support for RFIDs December 2008 6. Security Considerations 7. IANA Considerations 8 References 8.1 Normative References [HIP] R. Moskowitz, P. Nikander, P. Jokela, T. Henderson, Identity Protocol, RFC 5201, April 2008 8.2 Informative References [EPC] Brock, D.L, The Electronic Product Code (EPC), A Naming Scheme for Physical Objects, MIT AUTO-ID CENTER, 2001. [PML] Brock, D.L - The Physical Markup Language, MIT AUTO-ID CENTER, 2001. [EPCGLOBAL] EPCglobal, EPC Radio Frequency Identity Protocols Class 1 1516 Generation 2 UHF RFID Protocol for Communications at 860 MHz- 960 MHz Version 1517 1.0.9, EPCglobal Standard, January 2005. [NIST-800-108] NIST Special Publication 800-108, Recommendation for Key Derivation Using Pseudorandom Functions [SEC] S. Weis, S. Sarma, R. Rivest and D. Engels. "Security and privacy aspects of low-cost radio frequency identification systems." In D. Hutter, G. Muller, W. Stephan and M. Ullman, editors, International Conference on Security in Pervasive Computing - SPC 2003, volume 2802 of Lecture Notes in computer Science, pages 454- 469. Springer-Verlag, 2003. Author's Addresses Pascal Urien Telecom ParisTech 37/39 rue Dareau, 75014 Paris, France Email: Pascal.Urien@enst.fr Urien Expires June 2009 [Page 18] HIP support for RFIDs December 2008 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. 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. Urien Expires June 2009 [Page 19]