Network Working Group S. Guthery Internet Draft S. Marks Document: draft-guthery-ip7816-01.txt Mobile-Mind Expires: July, 2001 January, 2001 Category: Experimental IP and ARP over ISO 7816 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document describes the transport of IP datagrams and ARP messages over the ISO 7816 link layer of integrated circuit ("smart") cards. Guthery Experimental - Expires July 2001 1 IP and ARP over ISO 7816 January 2001 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Overview...........................................................2 Conventions used in this document..................................2 Motivation.........................................................3 Terminal-to-ICC....................................................3 ICC-to-Terminal....................................................4 ARP and RARP Message Format........................................4 Caches.............................................................5 ICMP and the ISO 7816-4 Status Word................................5 Maximum Transmission Unit..........................................6 IPv6 Considerations................................................6 Mobile IP Considerations...........................................6 Security Considerations............................................6 References.........................................................7 Author's Addresses.................................................8 Full Copyright Statement...........................................8 Overview ISO/IEC 7816-3 [4] describes an asynchronous half-duplex character transmission protocol called "T=0" between a terminal and an integrated circuit card ("ICC" or "smart card"). ISO/IEC 7816-3 Amendment 1 [5] describes an asynchronous half-duplex block transmission protocol called "T=1" also between a terminal and an ICC. We shall refer to these two protocols generically as the ISO 7816 link layer protocol. For the purpose of this document, a terminal together with all the ICCs physically connected to it is taken to be a connected network wherein the terminal acts as the gateway router. A 3GPP mobile telephone terminal with its ICC identity modules is an example of such a connected network. A session is an interval of time that starts when the ICC is reset and ends when either power is removed from the ICC or it is reset again. For example, a session might be from when a mobile phone is turned on and when is subsequently turned off or the time between when a card is inserted into an ATM machine and it is subsequently removed. 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 [1]. Guthery Experimental - Expires July 2001 2 IP and ARP over ISO 7816 January 2001 Motivation Smart cards are tamper-resistant hardware security modules, usually used for storing secret keys and performing cryptographic computations. Recently, there is a trend toward smart cards becoming application platforms, thus turning them into trusted computing bases. Communication with smart cards today is based upon link layer protocols such as T=0 and the construction of commands called Application Data Processing Units (APDU) for accessing the services of the card. This memo proposes a standard for communicating with cards using Internet protocols, thus connecting smart cards directly to the Internet and thereby lowering the barrier to integrating smart cards into Internet applications. Terminal-to-ICC An ISO 7816 link layer frame consists of 4 header octets, named CLA, INS, P1, and P2 in the ISO/IEC 7816-4 document, followed by a block of data octets. The initial two octets, CLA and INS are set to 0xFE to indicate a non-ISO 7816 multi-protocol datagram. P1 and P2 contain the PPP protocol number [11] and are set to 0x00 and 0x21 respectively to indicate an IP datagram. The data block is divided into two fields, named sequentially the Lc field and the data field. Lc contains the number of octets in the data field and is coded on three octets. The first octet is null and the second two octets contain the length of the following data field. The data field contains the IP datagram. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CLA = 0xFE | INS = 0xFE | PP = 0x00 0x21 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x00 | Length | IP Datagram ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- The ISO 7816 link layer protocol also specifies a third and final field called Le that contains the number of octets expected in response to the transmitted frame. Since none are expected, this field is empty. In the terminology of ISO 7816-4, a Terminal-to-ICC IP datagram is a Case 3 APDU. In accordance with ISO 7816-4, the ICC always returns a two-octet status word (SW) indicating the results of processing the frame. If the returned value is 0x9000 the frame was processed successfully. Guthery Experimental - Expires July 2001 3 IP and ARP over ISO 7816 January 2001 If the returned value is 0x91nn then the frame was processed successfully and the ICC has a 0xnn octet frame to return to the terminal. Any other status word is an error condition. ICC-to-Terminal The ISO 7816 link layer protocols are half-duplex with the terminal always initiating the communication. In order to enable IP packets to flow from the ICC to the terminal, the terminal MAY regularly poll the ICC by sending it the above-described header with the Lc field set to null. If the ICC returns only the two-octet status word 0x9000, then the ICC has no IP frame for transmission. If the ICC returns the two-octet status word 0x91nn, then it has a 0xnn octet IP frame for the terminal that the terminal subsequently retrieves using the Case 2 GET RESPONSE APDU with Le set to nn. The reply to the GET RESPONSE APDU is a packet of nn+2 octets, the first nn octets of which are the octets indicated in the previous status word and the last two octets are the status word of this operation: +-------//--------+--------+--------+ | Packet | SW1 SW2 | +-------//--------+--------+--------+ If the outgoing IP datagram length exceeds 255 octets, multiple response fragments are sent. Fragments are chained by setting SW1 to 0x91 and SW2 to the number of octets in the following fragment. The final fragment sets SW1 to 0x90 and SW2 to 0x00. Each fragment with an SW1 of 0x91 causes another GET REPONSE APDU to be issued to retrieve the number of octets indicated by SW2. ARP and RARP Message Format An ISO 7816 connected network consists of a terminal together with all the ICCs that are physically connected to it. Each physical connection is through an interface device (IFD) that has a 16-bit address on the terminal. For example, a 3GPP mobile telephone may contain a Subscriber Identity Module (SIM) and a electronic purse ICC. A WAP phone may contain a SIM and a Wireless Identity Module (WIM). An ISO 7816 connected network is structurally similar to the Logical IP Subnetwork (LIS) of ATM networks [8] since each of the ICCs can communicate directly with the terminal but not with each other. The ISO 7816 ARP/RARP protocol uses the same packet format as ARP for Ethernet. ARP packets shall be transmitted with the assigned ISO 7816 hardware type code, 29. ARP packets shall be accepted by the ICC only if received with this hardware type. Guthery Experimental - Expires July 2001 4 IP and ARP over ISO 7816 January 2001 ar$hrd (16 bits) shall contain the ISO 7816 specified hardware type value, 29 (decimal). ar$pro (16 bits) shall contain the IP protocol code 2048 (decimal). ar$hln (8 bits) shall contain 2. ar$pln (8 bits) shall contain 4. ar$op (16 bits) shall contain 1 for requests, 2 for responses. ar$sha (16 bits) in requests shall contain the requester's IFD address. In replies it shall contain the target node's IFD address. ar$spa (32 bits) in requests shall contain the requester's IP address if known, otherwise zero. In replies it shall contain the target node's IP address. ar$tpa (32 bits) in requests shall contain the target's IP address if known, otherwise zero. In replies it shall contain the requester's IP address. ar$atn (8 bits) is the octet length of following ar$atr. ar$atr (n octets) in requests shall contain the requester's ATR. In replies it shall contain the target node's ATR. Support for ARP and RARP is OPTIONAL. Caches The default entry in the route cache of an ICC contains SHOULD be the terminal. An ICC MAY maintain a route cache that consists of solely of this entry. Maintenance of an ARP cache by an ICC during a session is OPTIONAL but an ICC SHALL NOT maintain an ARP cache between sessions. In other words, the ARP cache is zeroed upon ICC reset. ICMP and the ISO 7816-4 Status Word ISO/IEC 7816-4 [6] describes a two-octet status word (SW) that is transmitted from the ICC to the terminal both as a response to a frame going from the terminal to the ICC and in association with a frame being transmitted from the ICC to the terminal. These status words may be translated into Internet Control Message Protocol (ICMP) [7] messages by the terminal and subsequently sent to the node corresponding with the ICC. Neither this mapping nor the situations in which it is used are covered in this document. Guthery Experimental - Expires July 2001 5 IP and ARP over ISO 7816 January 2001 Maximum Transmission Unit The maximum size of a T=0 data field is 65,535 octets. There is no provision in the protocol for fragmentation or, in ISO 7816 terms, chaining of T=0 frames. Therefore the MTU for T=0 is 65,535. The maximum size of a T=1 data field is 247 octets. An arbitrary number of T=1 frames can however be chained so there is effectively no MTU for T=1. The effective upper bound on the size of an ISO 7816 IP datagram is however not determined by the properties of the link layer protocol but rather the random access memory (RAM) resources of the ICC to hold the incoming and outgoing datagrams. Smart cards that are expected to support an Internet protocol stack can also be expected to have a RAM memory of at least 756 octets. Therefore the MTU for IP over ISO 7816 is set to the maximum datagram that all hosts must be prepared to accept, namely 576 octets. IPv6 Considerations It is desirable to be able to give a smart card its own static IP address and therefore it is expected that IPv6 will be more attractive than IPv4 for smart card applications. IPv6 requires that the MTU be at least 1280 octets. This will typically require that both incoming and outgoing IP datagrams be assembled in the non-volatile memory of todayĘs smart cards. This in turn will cut down on transmission speeds and generate wear and tear on this memory that is beyond current life cycle expectations. There is however ICC hardware in the product pipeline that can alleviate this problem (by for example providing more RAM or faster and more robust non-volatile memory) in the IPv6 rollout timeframe. Mobile IP Considerations Smart cards will be among the most mobile Internet nodes, not only when they are in a mobile connected network such as a 3GPP handset but also when they travel from place to place on sneaker net. Indeed it might be said that smart cards make sneaker net part of the Internet. It is expected that there will be applications for smart cards with static IP addresses and applications for smart cards with dynamic IP addresses. The capabilities of the terminal, the smart cardĘs gateway, will be but one of the many factors that determine which of these two alternatives is chosen. Security Considerations Security issues are not discussed in this memo. Guthery Experimental - Expires July 2001 6 IP and ARP over ISO 7816 January 2001 References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate requirement Levels", BCP 14, RFC 2119, March 1997 3 Postel, J., "Internet Protocol", RFC-791, USC/Information Sciences Institute, September 1981. 4 ISO/IEC 7816-3 Identification cards - Integrated circuit(s) cards with contacts - Part 3: Electronic signals and transmission protocols, First edition, September 15, 1989. 5 ISO/IEC 7816-3 Identification cards - Integrated circuit(s) cards with contacts - Part 3: Electronic signals and transmission protocols. Amendment 1: Protocol type T=1, asynchronous half duplex block transmission protocol. Amendment 1, December 1, 1992. 6 ISO/IEC 7816-4 Identification cards - Integrated circuit(s) cards with contacts - Part 4: Interindustry commands for interchange. 7 Postel, J., "Internet Control Message Protocol", RFC-792, STD 5, USC/Information Sciences Institute, September 1981. 8 Laubach, M. and J. Halpern, "Classical IP and ARP over ATM," RFC 2225, April 1998. 9 Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982. 10 Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse Address Resolution Protocol", STD 38, RFC 903, Stanford, June 1984. 11 Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. 12 Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC 1122, October 1989. Guthery Experimental - Expires July 2001 7 IP and ARP over ISO 7816 January 2001 Author's Addresses Scott Guthery Mobile-Mind 24 Church Street Phone: 1-617-926-6888 Watertown, MA USA Email: sguthery@mobile-mind.com Scott Marks Mobile-Mind 1808 Rolling Road Phone: 1-919-929-1436 Chapel Hill, NC USA Email: smarks@mobile-mind.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Guthery Experimental - Expires July 2001 8