Internet DRAFT - draft-guthery-ip7816
draft-guthery-ip7816
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
