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

Versions: 00


   Internet Draft
   Document: draft-urien-smarttp-00.txt                Schlumberger CP8
   Expires: December, 2001                                    June 2001
   Category: Experimental

                          Smart Transfer Protocol

Status of this Memo

   This document is an Internet-Draft and is NOT offered in accordance
   with Section 10 of RFC2026, and the author does not provide the IETF
   with any rights other than to publish as an Internet-Draft

   This document is an Internet-Draft. 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."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice.

   Copyright (C) Bull CP8 (2001)
   All Rights Reserved

Relevant patent.

   European patent, WO0010139, Pascal Urien, "Method for communication
   between a user station and a network, in particular as internet and
   implementing architecture".

Urien                      Expires December 2001                [Page 1]

INTERNET DRAFT              Smart Transfer Protocol            June 2001


   This note describes a protocol named Smart Transfer Protocol
   (SmartTP).This protocol defines data exchange mechanisms, which
   overcome ISO 7816 standard constraints, and which have been designed
   in order to transform a smartcard or an embedded system, into an
   internet node. This function is achieved through a cooperation
   between a terminal and an ICC, which allows the ICC to share the
   terminal TCP/IP stack.

Table of Contents.

   1 Terminology.......................................................3
   2 Conventions used in this document.................................3
   3 Motivation........................................................3
   4 Architecture......................................................4
   5 Relation to ISO 7816..............................................6
    5.1 Communication from terminal to ICC ............................8
    5.2 Communication from ICC to Terminal ............................8
   6 SmartTP protocol..................................................8
    6.1 Overview ......................................................8
    6.2 SmartTP_PDU ...................................................9
      6.2.1 Source reference ..........................................9
      6.2.2 Destination reference .....................................9
      6.2.3 Flags .....................................................9
      6.2.4 Information ..............................................10
      6.2.5 Token ....................................................10
      6.2.6 Notation .................................................10
      6.2.7 Implicit token ...........................................10
    6.3 SmartTP entity ...............................................10
      6.3.1 Basic design rules .......................................10
    6.4 SmartTP protocol rules .......................................11
      6.4.1 SmartTP entity ...........................................11
      6.4.2 Smart Agent ..............................................11
    6.5 SmartTP agents ...............................................12
    6.6 Example of server Agent state machine ........................13
    6.7 Example of client agent state machine ........................14
    6.8 A TCP network agent example. .................................15
    6.9 Traces .......................................................16
      6.9.1 Web Server Agent. ........................................16
      6.9.2 Proxy Agent. .............................................17
   7 Relation to other standards......................................18
   8 Assigned number..................................................18
   9 Authors' Addresses...............................................20
   10 References......................................................20

Urien                     Expires December 2001                 [Page 2]

INTERNET DRAFT              Smart Transfer Protocol            June 2001

1 Terminology

   AMUX              APDU Multiplexor.
   APDU              Application Protocol Data Unit.
   CSL               Card Smart Layer.
   HSL               Host Smart Layer.
   HTTP              Hyper Text Transfer Protocol.
   ICC               Integrated Circuit Card
   IP                Internet Protocol.
   OSI               Open System Interconnection.
   PDU               Protocol Data Unit.
   SAP               Service Access Point.
   SL                Smart Layer.
   SmartTP           Smart Transfer Protocol.
   SmartTP Agent     an autonomous software entity
   SmartTP_PDU       SmartTP protocol data unit
   SSL               Secure Socket Layer.
   TCP               Transmission Control Protocol.

2 Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119[2].

3 Motivation

   Smartcard is a tamper resistant device, it is a safe place to store
   information or to process cryptographic algorithms.

   ISO 7816 [4] standards have defined communication mechanisms between
   computer and smartcard; data are carried in APDUs (Application
   Protocol Data Unit), which in turn are exchanged through a serial
   link, according to transmission protocols like T=0 or T=1. This
   standard only define a set of low level commands, (typically, writing
   orders, reading orders, or cryptographic functions invocation);
   consequently an application which uses smartcard must be adapted for
   each type of these devices. One benefit of the SmartTP protocol, is
   to develop an unique software stack for each computer type, that
   works with all existing cards, implementing SmartTP.
   Most computers are connected to internet and includes a TCP/IP stack;
   furthermore there is an increasing need to enhance internet
   application security. The goal of SmartTP is to provide an internet
   access to an ICC, by sharing the terminal TCP/IP stack. Smartcard
   implements security functions (authentication, privacy, data
   integrity), as an example, it performs a subset of the SSL (TLS)
   protocol, which is transported through the internet network by IP
   packets, sent/received to/from terminal. It should be noticed that
   computers need card reader to work with smartcard.

Urien                      Expires December 2001                [Page 3]

INTERNET DRAFT              Smart Transfer Protocol            June 2001

    In this memo card reader will be consider as a part of the computer
   hardware, even if generally it's a separate device. Most computers
   operating systems support the PC/SC standard [7] specified in 1996 by
   a set of computers and cards manufacturers.

4 Architecture

   In TCP/IP architecture, a network application (such as a web browser)
   is based on a model which includes the first four layers of OSI

   Layers 1 (physical layer) and 2 (data link layer) are materialized
   for example by an ethernet board or a modem. The computer reaches a
   network resource (ethernet board...) through a particular software
   interface, sometimes called low-level driver (for example NDIS is a
   low-level driver developed by Microsoft). In OSI terminology this
   driver interface is called a Service Access Point (SAP) of level 2

   |      Application layer      |
   |          HTTP, FTP          |
   |        Transport layer      |
   |          TCP - UDP          |
   |        Network layer        |
   |              IP             |
   |       Data link Layer  OSI2 |
   |       Physical  Layer  OSI1 |

   Figure 1 TCP/IP architecture

   In a similar way an internet application uses TCP/IP layers by means
   of a network library (for example the socket library) hosted by the
   computer. An internet application can work with such a library
   through SAP of OSI layer 3 (network layer) or OSI layer 4 (transport

Urien                      Expires December 2001                [Page 4]

INTERNET DRAFT              Smart Transfer Protocol            June 2001

   In summary, a computer offers three network access points :
   - A SAP2 at network board level (or modem).
   - A SAP3 at network level (IP).
   - A SAP4 at transport level (TCP)

   An application working with a SAP4,uses the whole computer TCP/IP

   A SmartTP agent, is an autonomous software entity located either in a
   terminal or in an ICC. Agents exchange information, and follow rules
   according to a specific protocol (SmartTP). They can be located
   either in computer (terminal agent) or in ICC (card agent). They may
   use computer network resources (network agent) or not (local agent).
   According to these criteria's we shall distinguish three types of
   SmartTP agents, terminal-local, card-local, card-network.

   A network agent, which is always hosted in a computer, works with a
   particular SAP, therefore we should distinguish three kinds of such
   agents according to the communication layer in which there are

   The SmartTP protocol enables smartcard to access an IP network via
   two agents, one running in computer (a network terminal agent) and
   the other running in card (a local card agent). These two agents
   exchange application data (HTTP, SSL...) transported by SmartTP PDUs
   and APDUs.

   A communication stack, compatible with computers supporting 7816
   standards is presented in figure 2, and includes three kinds of
   functional blocks:

   A- OSI layer 1 and 2, supporting ISO 7816-3 transmission protocol.

   B- AMUX layer which routes (in terminal or smartcard) APDUs to/from a
   smart layer.

   C-Smart Layer, which is named HSL (Host Smart Layer) on computer side
   and CSL (Card Smart Layer) on ICC side. This layer includes one or
   several SmartTP agents, and a SmartTP entity.

   Agents process data carried by APDUs. SmartTP entity acts as a switch
   which routes incoming APDUs to the right agent. An application sends
   APDUs to the smartcard using APIs, made available by the host
   operating system. We call AMUX (APDU Multiplexor) the layer located
   in the card or in the terminal which switches the APDUs stream
   towards an ICC or a host application.

Urien                      Expires December 2001                [Page 5]

INTERNET DRAFT              Smart Transfer Protocol            June 2001

                  HOST SYSTEM                    SMARTCARD
   +--------------------------------------+ +-------------------+
   |                     Host Smart Layer | | Card Smart Layer  |
   |Network Library              HSL      | |        CSL        |
   |+-----------+  +----+ +--------------+| |+-----------------+|
   ||Layer4-TCP |--|SAP4|-|+-----+ +-----+| || +-----+ +-----+ ||
   |+-----------+  |    | ||Smart| |Smart|| || |Smart| |Smart| ||
   |      |        |    | ||Agent| |Agent|| || |Agent|.|Agent| ||
   |+-----------+  |    | |+-----+ +-----+| || +-----+ +-----+ ||
   ||Layer3-IP  |--|SAP3|-|   |       |   | ||    |       |    ||
   |+-----+-----+  +----+ |   |       |   | ||    |       |    ||
   |      |               |+-------------+| ||+---------------+||
   |+-------------------+ |SmartTP entity|| |||SmartTP entity |||
   || Low Level     SAP2|-|+-------------+| ||+---------------+||
   |+   driver          | +--------------+| |+-----------------+|
   |+-------------------+         |       | |         |         |
   |      |               +--------------+| |  +-------------+  |
   |      |               |     AMUX     || |  |    AMUX     |  |
   |      | Ethernet      |  ISO 7816-4  || |  | ISO 7816-4  |  |
   |MODEM | Board         +--------------+| |  +-------------+  |
   |  |   |   |       Card reader |       | |         |         |
   |+-----------------+   +-------------+|| |         |         |
   || +--------- ---+ |   |+--- --------+|| |  +-------------+  |
   || |   Layer2    | |   ||   Layer2   ||| |  |   Layer2    |  |
   || |DataLinkLayer| |   || ISO 7816-3 ||| |  | ISO 7816-3  |  |
   || +-------------+ |   |+------------+|| |  +-------------+  |
   ||     |           |   |       |      || |         |         |
   || +-------------+ |   |+------------+|| |  +-------------+  |
   || |   Layer1    | |   ||   Layer1   ||| |  |   Layer1    |  |
   || |             | |   || ISO 7816-2 ||| |  | ISO 7816-2  |  |
   || +-------------+ |   |+------------+|| |  +-------------+  |
   |+-----------------+   +--------------+| |         |         |
   |      |                      |        | |         |         |
   +------|----------------------|--------+ +---------|---------+
          |                      |                    |
       NETWORK                   +--------------------+

   Figure 2 SmartTP architecture

5 Relation to ISO 7816

   An application located in a smartcard communicates with the outside
   world by means of application protocol data unit (APDU), which are
   exchanged through the serial link between card and reader. An APDU
   contains either a command message or a response message sent from
   reader to card or conversely. The dialogue is carried out according
   to a command/response paradigm; terminal sends a request, ICC
   replies. In fact the ISO 7816-4 layer defines the equivalent of an
   OSI session since it fixes the rules for the dialogue between ICC and

Urien                      Expires December 2001                [Page 6]

INTERNET DRAFT              Smart Transfer Protocol            June 2001

   An APDU command consists of five bytes CLA INS P1 P2 P3. The first
   two bytes (CLAss, INStruction) indicate the nature of the requested
   operation (writing, or reading for example).The two following (P1 P2)
   provide more details about that operation (for example an address).
   The last one (P3) specifies either the length of following data
   block, or the length of the expected ICC response.

   The response carries optional data bytes, and ends by two status
   bytes SW1 and SW2. Status 90 00 (SW1, SW2), means that no error had
   occurred during the previous command.

   The length of the response data, which is not known before hand is
   obtained by interpreting the two status bytes; SW1 shall be 61 or 9F,
   and SW2 shall give the total length of the data issued by the card.
   This procedure is in conformance with ISO 7816 [4] or ETSI standard
   (GSM 11.11 ([5]).

   ISO 7816 services are used by SmartTP to exchange PDU between
   smartcard and computer. Error recovery functions are performed by
   7816 communication protocols, SmartTP_PDU transport is assumed by two
   specific APDUs, named SmartTP_Write and SmartTP_Read.

   |   SmartTP Agent   +
   |   SmartTP Entity  |
   |   7816 Standards  +

   Figure 3, relation between smart layer and ISO 7816

   Figure 3 summarizes the relation between SmartTP and ISO 7816.
   Agents, which implement internet application, exchange information
   according to the SmartTP protocol. SmartTP_PDU are transported using
   ISO 7816 facilities, but other smartcard standards could be
   supported, if necessary, in future version.

Urien                      Expires December 2001                [Page 7]

INTERNET DRAFT              Smart Transfer Protocol            June 2001

5.1 Communication from terminal to ICC

   An APDU named SmartTP_WRITE is used to send SmartTP_PDU from a
   terminal to a smartcard, it consists of five bytes and a smartTP_PDU:

   SmartTP_WRITE: 10 C2 BC 00 xx SmartTP_PDU,

   where xx is the length (in bytes) of the SmartTP_PDU. BC 00 is the
   protocol identifier (PID) of SmartTP stack (Bull CP8 protocol #00).

   ICC always returns a two bytes status 61 yy or 9F yy where yy is the
   response length. Status 90 00 may be returned to notify that PDU
   response is an implicit token.

5.2 Communication from ICC to Terminal

   An APDU named SmartTP_READ is used to get a SmartTP PDU produced by
   an ICC. This APDU is always issued following a SmartTP_WRITE, it is
   defined in ISO 7816 as a GET RESPONSE.

   SmartTP_READ: 10 C0 00 00 yy

   where yy is the exact length of the expected SmartTP_PDU.

   ICC returns a smartTP_PDU whose length is equal to yy bytes, and adds
   a two words status byte SW1 SW2.

6 SmartTP protocol

6.1 Overview

   SmartTP can be thought as a light version of the well known TCP
   protocol[3]. In TCP, six flags (URG, ACK, PSH, RST, SYN, and FIN) are
   used to manage a connection. Each application, working over this
   connection (a client or a server)is associated to a port, identified
   by a two bytes number, which is a well known value for a server, and
   an ephemeral value for a client. The usual size of TCP header is
   around 20 bytes.

   SmartTP only supports port and flag concept, therefore its header
   size is five bytes, and includes three fields, source port (2 bytes),
   destination port (2 bytes) and flag (1 byte).

   SmartTP PDUs are transported between terminal and ICC using 7816
   protocols, which are in charge of error recovery, therefore it's not
   necessary to define error detection and correction mechanisms.

Urien                      Expires December 2001                [Page 8]

INTERNET DRAFT              Smart Transfer Protocol            June 2001

6.2 SmartTP_PDU

   +Source Reference+Destination Reference+ Flags + Information +
   +   LSB    MSB   +   LSB         MSB   + f7.f0 + 0-240 bytes +

   Figure 4, SmartTP_PDU

   A SmartTP PDU is divided in four parts
   - source reference      (2 bytes)
   - destination reference (2 bytes)
   - flags                  (1 byte)
   - information          (optional)

   Agents are identified by a two bytes number (a reference) which, as
   in TCP, can be either a fix value (server agent), or pseudo random
   (and ephemeral) value (client agent).

6.2.1 Source reference
   The reference of agent which has issued this SmartTP_PDU. It's
   transmitted in the order LSB - MSB.

6.2.2 Destination reference
   The reference of agent to which PDU is sent. It is transmitted in the
   order LSB - MSB. If the most significant bit (b15) is set,
   destination agent is located in the same smart layer (ICC or
   terminal), otherwise the SmartTP_PDU is sent towards the other smart

6.2.3 Flags

   +  f7  +  f6   +  f5 +  f4  +  f3* +  f2*  +  f1*  +  f0* +
   + Open + Close + Ack + Nack + Data + Block + Write + Read +

   Figure 4, flags field, *: only used by Agents.

   This field is a set of 8 bit indicators (f7...f0). Indicators f3,
   f2,f1,f0 are not meaningful for SmartTP entity, and are only used by
   - f7 Open, when set, this indicator means that a session is being
   opened between destination and source reference.
   - f6 Close, when set, this indicator means that a session had been
   closed between the destination and the source agent.
   - f5 Ack, this indicator is always set by the source SmartTP entity
     and is reserved for future used, therefore agent never uses this

Urien                      Expires December 2001                [Page 9]

INTERNET DRAFT              Smart Transfer Protocol            June 2001

   - f4 Nack, when set this flag indicates that an error had been
   detected, either by an agent or a SmartTP entity. Upon reception of
   this event an agent will close its current session.

   - f3 Data, this flag may be used by a destination agent to determine
   whether a SmartTP_PDU information is interpreted as a command or
   data. This indicator is always reset for a PDU sent to a SmartTP
   - f2 Block, when set, this indicator notifies to a destination agent
   that a source agent is waiting for a response and remains in a freeze
   - f1 Write, this indicator is set to indicate a writing operation.
   - f0 Read, this indicator is set to indicate a reading operation.

6.2.4 Information
   This field is optional, its maximum length value is dependent on the
   used transmission protocol.

   This value is fixed to 240 bytes for ISO 7816 T=0 protocol.

   This value is fixed to 240 bytes for ISO 7816 T=1 protocol.

6.2.5 Token
   A Token is a PDU which contains no information, its length is
   therefore equal to five bytes. A Null Token is issued by SmartTP,
   whose source reference is null. On the contrary a data PDU includes
   information bytes.

6.2.6 Notation
   In the next sections , SmartTP_PDU exchanges will be represented
   according to the following notations:

   - A PDU begins and ends by a bracket []
   - s=, denotes the source reference.
   - d=, denotes the destination reference.
   - Set indicators (Ack, Nack, Open, Close, Data, Block, Read, Write)
   are separated by the "+" sign. If no indicator is set, the "null"
   symbol is used.
   - information if any, is represented by the string data. This symbol
   is omitted if the information field is empty.

   Some examples are listed below:

   [s=2,d=4567,null], a token with no indicator set.
   [s=4567,d=5, Block+Write], a token whose indicators Block and Write
   are set.

   [s=56,d=5432, Open, data], a PDU whose open indicator is set and
   which includes data.

Urien                      Expires December 2001               [Page 10]

INTERNET DRAFT              Smart Transfer Protocol            June 2001

6.2.7 Implicit token

   An ICC smartTP entity receives a PDU [s=SourceReference,
   d=DestinationReference,...]. An implicit token is a response PDU
   whose content is [s=DestinationReference, d=SourceReference, Ack].

6.3 SmartTP entity

   SmartTP is in charge of switching packets to/from the
   destination/source agent. It's associated to a Null reference;
   SmartTP entity acts in fact as a server agent, whose reference is
   equal to zero.
                                 Incoming PDU
                     <s=RefSource, d=RefDest, flags, data>
                                 | RefDest |
                                 |   =0    |
                                  /       \
                                 /         \
                              No/           \Yes
                               /             \
                       +------+-----+      Send token
                       |   RefDest  |      <s=0, d=0, Ack>
                       |  =RefAgent |
                          /      \
                         /        \
                      No/          \Yes
                       /            \
                 +----+----+  PDULength = SmartTP2Agent(PDU)
                 |  Open   |  if (PDULength =0
                 |         |  PDU = token = <s=0, d=0, Ack>
                 +-+-----+-+  Set Ack
                  /       \   Send PDU
                 /         \
              No/           \Yes
               /             \
           Send token        Send
           <s=0, d=0, Ack>   <s=0, d=RefSource, Close+Ack+Nack>

   Figure 6, PDU processing, by smartTP entity

6.3.1 Basic design rules

   Let's assume that a PDU <s=RefSource, d=RefDest, flags, data> had
   been received. Three cases are taken into account:

Urien                      Expires December 2001               [Page 11]

INTERNET DRAFT              Smart Transfer Protocol            June 2001

   Case 1 -If the destination reference (RefDest) is null, a token
   (<s=0, d=0, Ack>) is always generated on the ICC side, while on
   terminal side no PDU is produced.

   Case 2 - If the destination reference (RefDest) is not null and is
   affected to a client agent or a server agent, then it's routed
   towards the corresponding agent. If this agent generates no response
   , an Ack token (<s=0, d=0, Ack>) is always generated on the ICC side,
   while on terminal side no PDU is produced. When a PDU is produced,
   the Ack indicator is always set by SmartTP entity.

   Case 3 - If there is no match between the destination reference
   (RefDest) and an agent reference, a token (<s=0, d=0, Ack>) is
   generated if the Open indicator is not set; otherwise, a Nack token
   is produced (<s=0, d=RefSource, Ack+Close+Nack>)

6.4 SmartTP protocol rules

6.4.1 SmartTP entity

   Rule 1 -  SmartTP (ICC side) always sends a PDU following an incoming
   PDU; it can be either an agent generated PDU or a Null Token.

   Rule 2 - SmartTP (terminal side) never responds upon reception of a
   Null token.

   Rule 3 - SmartTP sends a Null Token if a PDU is received without the
   Open indicator set and with an unknown destination reference.

   Rule 4 - SmartTP produces a token with the Close indicator set upon
   the reception of an Open PDU whose destination reference is unknown.

6.4.2 Smart Agent

   Rule 1 - An agent ignores (no outgoing PDU is generated) every PDU
   whose open indicator is not set, and which can't be associated to an
   existing session.

   Rule 2 - An agent never responds (no outgoing PDU is generated) to a
   PDU whose close flag is set. If necessary a token will be generated
   by SmartTP entity.

   Rule 3 - Upon reception of a PDU whose source reference is null and
   with close indicator set, an agent closes all its open sessions, and
   no outgoing PDU is generated.

   Rule 4 - An agent always responds to a PDU whose blocking indicator
   is set, if necessary by a token.

Urien                      Expires December 2001               [Page 12]

INTERNET DRAFT              Smart Transfer Protocol            June 2001

6.5 SmartTP agents

   Two Agents are connected through a session. An agent is identified by
   an integer (ranging between 1 and 65535, value 0 is assigned to
   SmartTP entity).

   The most significant bit (b15) of this reference indicates if an
   agent is local (located in the same smart layer) or remote (b15=0).
   This feature means that agents can communicate within a smart layer
   or between two smart layers (terminal side and card side). A client
   sends a PDU of which the OPEN indicator is set (request for opening
   of session). A server receives this request for session opening. A
   server reference is constant; i.e. it is a well-known value. A
   session is identified by a couple, client reference, server
   reference. The client reference is chosen so that this couple is
   unique for a reasonable amount of time. The transmission of a PDU
   with the indicator CLOSE ends a session.

   There are six particular properties characterizing Agents :

   - Terminal, an agent located in the host system.
   - Card, an agent located in the card.
   - Local, an Agent which can't use network resources.
   - Network, an Agent, which can access to network.
   - Client, an agent which initializes a session (via the Open
   - Server, an agent which receives a request for opening a session
   (indicator Open is set).

   In the computer side, network agents are able to access the network
   resources (low-level driver, network library). From a TCP/IP point of
   view these agents are acting as server or client; they give an
   internet access to the card agents to which they are connected.

Urien                      Expires December 2001               [Page 13]

INTERNET DRAFT              Smart Transfer Protocol            June 2001

6.6 Example of server Agent state machine

        I n c o m i n g  PDU
                 |                  CT= Session Counter
            | O P E N |
            /          \
        Yes/            \No
          /              \
         +                +
     ----                 ----
    |CT=1|               |CT=0|
     ----                 ----
      |   \               /  \
    No|    \Yes       Yes/    \No
      +     +           +      +
    CT=1    Tx:Token  End  -------
    Sref=     +Close      |Source |
    Reference             |=Sref  |
    Source                 -------
    Tx:Token              /      \
                       No/        \Yes
                        /          \
                       +            +
                  ------      ================
                 |Source|     || Processing ||
                 |=Null |     ||  Http 1.1  ||
                  ------      ================
                  / \                |
              Yes/   \No             |
                +     +            -----
             -----     End        |CLOSE|
            |CLOSE|                -----
             -----                 /  \
             /  \               No/    \Yes
          No/    \Yes            /      \
           /      \             +        +
          +        +         -----       CT=0
        End       CT=0      |BLOCK|      End
                  End        -----
                             /  \
                          No/    \Yes
                           +     +
                         End     Tx:Token

   Figure 7, example of a smartTP server state machine

Urien                      Expires December 2001               [Page 14]

INTERNET DRAFT              Smart Transfer Protocol            June 2001

6.7 Example of client agent state machine

              I n c o m i n g  PDU
                   |CT=0 |
                    -----    CT=Session Counter
                   /      \
               Yes/        \No
                 /          \
                +            +
              End          --------
                          | Source |
                          | =Sref  |
                           /    \
                          /      \
                       No/        \Yes
                        /          \
                       +            +
                  ------      ================
                 |Source|     || Processing ||
                 |=Null |     ||            ||
                  ------      ================
                  /   \              |
              Yes/     \No           |
                /       \            |
               +         +         -----
            -----         End     |CLOSE|
           |CLOSE|                 -----
            -----                  /  \
            /  \                No/    \Yes
         No/    \Yes             /      \
          /      \              +        +
         +        +          -----       CT=0
       End       CT=0       |BLOCK|      End
                 End         -----
                             /  \
                          No/    \Yes
                           /      \
                          +        +
                         End     Tx:Token

   Figure 8, Example of SmartTP client state machine.

Urien                      Expires December 2001               [Page 15]

INTERNET DRAFT              Smart Transfer Protocol            June 2001

6.8 A TCP network agent example.

                          WAIT       TCP
   IDDLE                AND BLOCK  TRANSMIT           LEAVE
   -----                ---------  --------           -----
     |                      |         |                 |
     |                      |         |                 |
     |TCP Server            |         |                 |
     |Connection Established|         | Rx:Close PDU    |
     |--------------------->|-------->|------------->   |
     |Tx : Token Open Block |Rx:Data  | Network Error   |
     |                      |   Write |                 |
     |                      |   Block |                 |
     |                      |         |                 |
     |                      |         |                 |
     |       TCP CONNECT    |         |   TCP RECEIVE   |
     |       -----------    |         |   -----------   |
     |          |           |         |        |        |
     |          |TCP        |         |        |        |
     |outgoing  |connection |<--------|<------ |Network |
     |TCP client|Established|Tx:Token |Rx:Data |Error   |
     |--------->|---------->|   Block |   Write|------->|
     |Rx:Data   | Tx:Token  |         |   Block|Rx:Close|
     |   Open   |    Block  |                  |   PDU  |
     |   Block  |           |Rx:Token          |        |
     |          |           |----------------->|        |
     |          |           |                  |        |
     |          |           |Tx:Data Write     |        |
     |          |           |        Block     |        |
     |          |           |<-----------------|        |
     |          |           |                           |
     |          |           |Rx:Close PDU               |
     |          |           |-------------------------->|
     |          |           |                           |
     |          |                                       |
     |          | Rx:Close PDU                          |
     |          | ------------------------------------->|
     |          | Network error                         |
     |          |                                       |
     |                                                  |
     |                        [Network Error]=>Tx:Close |
     | <----------------------------------------------- |
     |               [Rx:Close]=>TCP connection release |
     |                                                  |

   Figure 9, example of a network agent state machine.

   A TCP network agent works as a protocol translator between SmartTP
   and TCP. It's organized around a central state WAIT_AND_BLOCK in
   which no operation is performed.

Urien                      Expires December 2001               [Page 16]

INTERNET DRAFT              Smart Transfer Protocol            June 2001

   The system is waiting for an acknowledgment (a token), which will
   specify the next agent state (writing to network or reading from
   network). This agent includes five states.

   1-IDDLE, in this state a TCP server (SmartTP client) is awaiting for
   an incoming TCP connection or a SmartTP server is waiting for an
   incoming OPEN PDU. In the case of an incoming TCP connection an open
   token is sent to a server agent, agent switches to the WAIT_AND_BLOCK

   2- TCP_CONNECT, this state in meaningful only for a TCP client. An
   incoming open PDU has been received. The associated data specified
   the host name (or IP address) and the TCP port. A TCP connection is
   in progress (SYN has been sent). Upon connection completion (TCP
   established state)a block token is sent, the agent switches to the
   WAIT_AND_BLOCK state. If a network error occurs or if a close PDU is
   received agent switches to the LEAVE state.

   3- WAIT_AND_BLOCK, in this state agent is waiting for an incoming
   PDU; no network operation is in progress. According to an incoming
   PDU, agent can switch to the TCP_TRANSMIT state (if a writing
   operation is required) or to the TCP_RECEIVE state (if a token has
   been received). If a close PDU is received agent switches to the
   LEAVE state.

   4- TCP_TRANSMIT, data are being sent through the network. If a
   network error occurs or if a close PDU is received agent switches to
   the LEAVE state. Upon transmission completion a block token is sent,
   agent switches to the WAIT_AND_BLOCK state.

   5- TCP_RECEIVE, agent is awaiting data from the network. When a write
   PDU is received agent switches to the TCP_TRANSMIT state. If a
   network error occurs or if a close PDU is received agent switches to
   the LEAVE state. When data are received from the network a write
   block PDU is sent, agent switches to the WAIT_AND_BLOCK state.

   6- LEAVE, if a network error had occurred a close token is sent,
   otherwise a close PDU has been received and the TCP connection is

6.9 Traces

6.9.1 Web Server Agent.

   In this scenario a browser opens an http session with a web server
   agent (#2) located in an ICC. A network agent (#15361) performs the
   translation between TCP and SmartTP protocols.

   A web browser opens a TCP connection with a network agent which acts
   as a TCP server (using for example port 80).

Urien                      Expires December 2001               [Page 17]

INTERNET DRAFT              Smart Transfer Protocol            June 2001

   [s=15361,d=2,Open+Block+Ack], [s=2,d=15361,Ack].

   An http request is sent from browser towards an ICC web server.
   [s=15361,d=2,Write+Block+Ack,data], [s=2,d=15361,Ack].

   Last part of the request is sent.

   The ICC server sends its response.
   [s=2,d=15361,Write+Block+Ack,data], [s=15361,d=2,Block+Ack].
   [s=2,d=15361,Write+Block+Ack,data], [s=15361,d=2,Block+Ack].

   The card server closes the TCP connection.

6.9.2 Proxy Agent.

   In this scenario a browser opens an http session with a web server
   agent (#2) located in an ICC. A network agent (#15360) performs the
   translation between TCP and SmartTP protocols. A new session is then
   opened between an ICC client agent (#2559) and a network agent (#1)
   which acts as a TCP client and performs the translation between TCP
   and SmartTP protocols.

   A first session is opened between a browser and network agent

   Web browser sends an http request to an ICC web server.
   [s=15360,d=2,Write+Block,data], [s=2,d=15360,Ack].

   Last part of the request is sent.

   ICC proxy opens a second connection towards an internet server.

   [s=2559,d=1,Open+Block+Ack,data], [s=1,d=2559,Block+Ack].

   ICC proxy sends data (an http request) to the internet server.
   [s=2559,d=1,Write+Block+Ack,data], [s=1,d=2559,Block+Ack].

   Last part of the request is sent.

   ICC proxy forwards data between the two terminal network agents.
   [s=1,d=2559,Block+Ack], [s=2,d=15360,Block+Ack], [s=15360,d=2,Ack],

Urien                      Expires December 2001               [Page 18]

INTERNET DRAFT              Smart Transfer Protocol            June 2001

   Data are received from the network.

   [s=15360,d=2,Block+Ack], [s=2559,d=1,Block+Ack], [s=1,d=2559,Ack],

   Agent #5 is ready to receive data again.

   Session end.
   The card proxy forwards data...
   [s=1,d=2599,Write+Block+Ack], [s=2,d=15360,Write+Block+Ack].

   Agent #15360 releases a (blocking) token.
   [s=15360,d=2,Block+Ack], [s=2559,d=1,Block+Ack].

   The web browser ends the TCP connection session, agent #15360 closes
   its session.
   [s=15360,d=2,Close+Ack], [s=2559,d=1,Close+Ack].

   Agent #1 closes its session with agent #2559, but two SmartTP_PDU
   which had been produced before the session end are sent by HSL to
   CSL, CSL acknowledges each of them by a Null token.

   [s=1,d=2559,Ack], [s=0,d=0,Ack].
   [s=1,d=2559,Write+Block+Ack,data], [s=0,d=0,Ack].

7 Relation to other standards

   Agents can exchange information carried by SmartTP PDUs and routed by
   SmartTP entity. This architecture allows to design agents which are
   independent from the platform in which they are running. Therefore
   Smart Layer can work over communication stack which are not defined
   by 7816 standards. As an example SmartTP PDU, identified by a
   specific protocol number, can be transported in IPv4 or IPv6 packets.

8 Assigned number

   Network Agent TCP port is set to ???? + x, where x is a physical
   channel number between 0 and 3 (hexadecimal value).

   The standard (TCP client) network agent reference is set to 1. Data
   associated to the open PDU designed an internet server and port
   separated by the sign ":".

   The web agent (server) reference is set to 2.

   SmartTP protocol number is set to BC00.

Urien                      Expires December 2001               [Page 19]

INTERNET DRAFT              Smart Transfer Protocol            June 2001

9 Authors' Addresses

   Pascal Urien
   Schlumberger CP8
   68 route de Versailles - BP 45
   78431 Louveciennes Cedex

   eMail: Pascal.Urien@Bull.net

10 References

   1 Bradner, S., "The Internet Standards Process -- Revision 3", RFC
   2026, October

   2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
   Levels", RFC 2119, March 1997

   3 Postel, J., "Transmission Control Protocol", RFC 793, September

   4 ISO/IEC 7816, "Identification Cards - Integrated Circuit(s) Cards
   with Contacts_

   5 ETSI GSM 11.11, "Digital cellular telecommunications system (Phase
   2+) Specification of the Subscriber Identity Module - Mobile
   Equipment (SIM - ME) interface"

   6 ISO 7498, "Information Processing Systems - Open Systems
   Interconnection - Basic Reference Model "

   7 PC/SC, (c) 1996 CP8 Transac, HP, Microsoft, Schlumberger, Siemens
   Nixdorf, "Interoperability Specification for ICCs and Personal
   Computer Systems".

   8 T Berners Lee & All "Hypertext transfer Protocol - HTTP/1/1" -
   RFC2616 - June 1999

   9 Pascal Urien Internet Smartcard, a smartcard as a true Internet
   node", Computer Communication volume 23, issue 17 - October 2000

Urien                      Expires December 2001               [Page 20]

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