Network Working Group S.Guthery Internet Draft Mobile-Mind Document: draft-guthery-ip7816-00.txt Y.Baudoin Category: Experimental Touch Technologies J.Posegga Deutsche Telekom J.Rees University of Michigan February 2000 IP and ARP over ISO 7816-3 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. 1. Abstract ISO/IEC 7816-3 [4] describes a 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 a 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-3 data-link protocols. For the purpose of this note, a terminal together with all the ICCs inserted into it is taken to be a data-link layer subnetwork wherein the terminal acts as the gateway router for this subnetwork. Guthery EXPERIMENTAL - July 2000 1 IP and ARP over ISO 7816-3 February 2000 This memo describes the transport of IP datagrams and ARP messages over the ISO 7816-3 data-link layer. 2. 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 [2]. 3. Motivation Smart cards are tamper-proof security modules (servers), usually used for securely 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 smartcards today is based upon low-level protocols such as T=0 and the construction of APDUs (Application Data Processing Units) for accessing the services of the card from the outside. This memo proposes a standard for communicating with cards using Internet protocols, thus integrating smart cards into the Internet and lowering the barrier to integrating smart cards into Internet applications. 4. Terminal-to-ICC An ISO 7816-3 data-link frame consists of 5 header bytes (named CLA, INS, P1, P2 and P3 in the ISO/IEC 7816-3 documents) followed by a block of P3 data bytes. The initial two bytes, 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. P3 as indicated above is the length of the following data block. The data block contains the IP datagram. The ICC always returns a two-byte status word (SW) indicating the results of processing the frame. If the returned value is 0x9000 the frame was processed successfully. If the returned value is 0x61nn then the frame was processed successfully and the ICC has a 0xnn byte frame to return to the terminal. All other values of the status word indicate an error condition in which the frame was not processed successfully. Guthery EXPERIMENTAL - July 2000 2 IP and ARP over ISO 7816-3 February 2000 5. ICC-to-Terminal An ISO 7816-3 data-link is half-duplex with the terminal always initiating 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 P3 set to null. If the ICC returns only the two-byte status word 0x9000, then the ICC has no IP frame for transmission. If the ICC returns the two-byte status word 0x61nn, then it has a 0xnn byte IP frame for the terminal that the terminal subsequently retrieves for routing. 6. ARP and RARP Message Format An ISO 7816-3 subnetwork consists of a terminal together with all the ICCs that are physically connected to it. Each physical connection is through an interface device (IFD) which has a 16-bit address on the terminal. For example, a GSM 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-3 subnetwork 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-3 ARP/RARP protocol uses the same packet format as ARP for Ethernet. ARP packets shall be transmitted with a hardware type code that is yet to be specified. ARP packets shall be accepted only if received with this hardware type. ar$hrd (16 bits) shall contain a yet to be specified hardware type value. 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 Guthery EXPERIMENTAL - July 2000 3 IP and ARP over ISO 7816-3 February 2000 IP address if known, otherwise zero. In replies it shall contain the requester's IP address. ar$atn (8 bits) is the byte length of following ar$atr. ar$atr (n bytes) 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. 7. ICMP and the ISO 7816-4 Status Word ISO/IEC 7816-4 [6] describes a two-byte status word (SW) which 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 memo. 8. Maximum Transmission Unit The maximum data size of a T=0 data field is 255 bytes and the maximum size of a T=1 data field is 249. The Maximum Transmission Unit (MTU) of ISO 7816-3 datagrams is therefore set at 248. 9. Security Considerations Security issues are not discussed in this memo. 10. 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 Guthery EXPERIMENTAL - July 2000 4 IP over ISO 7816 January 2000 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. Guthery EXPERIMENTAL - July 2000 5 IP over ISO 7816 January 2000 10. Authors' Addresses Scott Guthery Mobile-Mind 80 Manemet Road, Newton, MA 02459-1451 USA Phone: +1 617 964 1794 Email: sguthery@mobile-mind.com Youri Baudoin Touch Technologies 2201 East Camelback Road, Suite 300B Phoenix, AZ 85016 USA Phone: +1 602 954 7760 Email: ybaudoin@touchtechnology.com Joachim Posegga Deutsche Telekom Technologiezentrum Darmstadt, Am Kavalleriesand 3 D-64295 Darmstadt, Germany Phone: +49 61 51 83-6715 Email: Joachim.Posegga@telekom.de Jim Rees University of Michigan Center for Information Technology Integration 519 West William Ann Arbor, MI 48109 USA Phone: +1 734 763 4174 Email: rees@umich.edu Full Copyright Statement "Copyright (C) The Internet Society (date). 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 implmentation 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 in the final draft output. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Guthery EXPERIMENTAL - July 2000 6