[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

   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


Html markup produced by rfcmarkup 1.120, available from https://tools.ietf.org/tools/rfcmarkup/