Internet Draft P.Urien Document: draft-urien-eap-ssc-01.txt M. Dandjinou Expires: June 2004 EAP-SSC Secured Smartcard Channel Status This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 obsolete 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. 1 Abstract This document describes a means of setting up an EAP secured channel between a Smart Card SC and an Authentication Server AS (e. g. RADIUS server), as well according to an asymmetric key exchange model as a symmetric key exchange model. This channel permits to convey in secure all other types of payload between the SC and the AS, for example the commands which can setup or update the Directory Information Base (DIB) associated to the LDAP (Lightweight Directory Access Protocol) in the Smart Card. Urien & All Informational - Expires June 2004 1 EAP-SSC Secured Smart Card Channel December 2003 Table of Contents 1 Abstract............................................................1 2 Overview............................................................3 3 EAP-SSC Protocol Data Unit..........................................3 3.1 EAP packet format (Informative)..................................3 3.2 EAP-SSC packet format............................................4 3.2.1 Type field....................................................4 3.2.2 Sub-Type field................................................5 3.2.3 Flags field...................................................5 3.2.4 Message Length field..........................................7 3.2.5 Payload field.................................................7 3.2.6 Digest field..................................................7 4 Setting up the Secured Smart Card Channel...........................7 4.1 SessionĘs Key (SK) calculation...................................8 4.1.1 Overview......................................................8 4.1.2 SessionĘs key calculation, Symmetric case.....................8 4.1.3 SessionĘs key calculation, Asymmetric case...................10 4.2 SessionĘs key validation........................................12 5 Secure Channel Messages exchanges..................................15 6 Segmentation issue.................................................16 7 LDAP messages......................................................16 8 Messages encryption................................................16 9 Examples of traces with plain text payload.........................18 9.1 Traces in a symmetrical key exchange context....................18 9.2 Traces in an asymmetrical key exchange context..................20 10 Intellectual Property Right Notice................................23 11 References........................................................23 12 Author's Addresses................................................23 Urien & All Informational - Expires June 2004 2 EAP-SSC Secured Smart Card Channel December 2003 2 Overview Security is the key problem to solve in all the new technologies that derived from 802.11 specifications if in the existent networks (PAN, LAN and MAN) we want to increase quickly their utilization. 802.1X [1] specifications which add changes to improve 802.11 technologies, require the framework of Extensible Authentication Protocol (EAP) RFC 2284bis [2] for application dependent authentication processes with a mutual authentication between the Supplicant and the Authenticator. When the Supplicant is partially in a Smart Card as it is described in [3][4], a particular protocol is needed to establish an EAP secured channel between this part of the Supplicant in the Smart Card and the Authentication Server via the Authenticator. The purpose of this paper is first to present this new protocol EAP-SSC (Extensible Authentication Protocol, Secured Smart Card Channel) with its mechanisms and procedures. Secondly we describe a manner for encoding the Protocol Data Unit (PDUs) which are used for setting up this channel. Finally we show how management commands for LDAP [5] [6] [7] oriented data-base stored on the Smart Card are securely embedded in these PDUs. 3 EAP-SSC Protocol Data Unit EAP-SSC is an authentication protocol for Smart Cards based on EAP. Before showing the format of its PDUs, let us remind the EAP packet format. 3.1 EAP packet format (Informative) We present in the figure 1 a summarized EAP packet format according to the specification of EAP in IETF RFC 2284bis. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 : EAP packet format. The Code field is one byte and identifies the type of EAP packet that can be assigned with 1 for request packet, 2 for response packet, 3 for successful authentication acknowledgement, and 4 for failure notification. The Identifier field is one byte length and allows matching of responses with requests. The Length field is two bytes length and corresponds to the length of the EAP packet including the Code, Identifier, Length and Data fields. The Data field is zero or more bytes length and its format depends on the Code field. It is that part which will keep all the particularities of EAP-SSC. Urien & All Informational - Expires June 2004 3 EAP-SSC Secured Smart Card Channel December 2003 3.2 EAP-SSC packet format EAP-SSC packet is encapsulated in the general EAP packet, in its non zero Data field and is structured like presented in the figure 2 hereafter: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Sub-Type | Flags | Message Length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . . Payload . . . . . . . . + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Digest + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 : EAP-SSC packet format. 3.2.1 Type field The Type field is one byte length. As described in RFC 2284bis, all EAP implementations MUST support Types values 1-4 corresponding to : 1 Identity; 2 Notification; 3 Nak (only for Response messages); 4 MD5-Challenge; 255 Vendor-specific. Additional EAP types have been defined later : 5 One-Time Password (OTP) (RFC 2289); 6 Generic Token Card (GTC); 13 EAP/TLS (RFC 2716) [8]; 18 EAP/SIM (see [9]). A new value of Type field is requested to IANA for distinguishing EAP on Smart Cards from others. In this document the value for EAP-Type corresponding to EAP-SSC will be denoted EAP-SSC-Type. The Identity Type is used to query the identity of the Supplicant. Generally, the Authenticator will issue this as the initial Request. It is the same type that will be used by the Supplicant to respond with its identity. The Notification Type is optionally used to convey a displayable message from the Authenticator to the Supplicant. The Supplicant SHOULD display this message to the user or log it if it cannot be displayed. It is intended to provide an acknowledged notification of some imperative nature. The Notification Request MAY be used to indicate an invalid authentication attempt prior to transmitting a new Identity Request (optionally, the failure MAY be indicated within the message of the new Identity Request itself). Urien & All Informational - Expires June 2004 4 EAP-SSC Secured Smart Card Channel December 2003 The Nak Type is valid only in Response messages. It is sent in reply to a Request where the desired authentication Type is unacceptable. Authentication Types are numbered 4 and above. This Response contains the authentication Type desired by the Supplicant. The MD5-Challenge Type is analogous to the PPP CHAP protocol [10] (with MD5 as the specified algorithm). The Request contains a "challenge" message to the Supplicant. A Response MUST be sent in reply to the Request. The Response MAY be either of Type 4 (MD5-Challenge) or Type 3 (Nak). The Nak reply indicates the Supplicant's desired authentication mechanism Type. All EAP implementations MUST support the MD5-Challenge mechanism. The One-Time Password system is defined in "A One-Time Password System" [11]. The Request contains a displayable message containing an OTP challenge. A Response MUST be sent in reply to the Request. The Response MUST be of Type 5 (OTP) or Type 3 (Nak). The Nak reply indicates the Supplicant's desired authentication mechanism Type. The Generic Token Card Type is defined for use with various Token Card implementations which require user input. The Request contains an ASCII text message and the Reply contains the Token Card information necessary for authentication. Typically, this would be information read by a user from the Token card device and entered as ASCII text. The EAP/TLS type is described in [8]. The EAP/SIM type is described in [9]. 3.2.2 Sub-Type field The Sub-Type field allows conveying several families of messages. At the moment this draft is presented, the following values are used for the Sub-Type field: * Sub-type = 1 means that the context of encryption corresponds to the symmetrical model, i.e. one supposes that the Smart Card and the Authentication Server share a secrecy commonly called secret key s. * Sub-type = 2 indicates that the context of encryption employed is that corresponding to the asymmetrical model or public key encryption, i.e. the Smart Card and the Authentication Server have each one a couple of keys (public key, private key) where only the owner of the private key is supposed to know it, while the public key is provided to any correspondent for deciphering the coded message that one sends to him. In follow-on documents, additional values MAY be defined. Symmetric and asymmetric key exchange authentication will be described later in this document. 3.2.3 Flags field This Flags field is one byte in length and its format depends on the Sub-Type field. For the Sub-Type values 1-2, the Flags field has the format shown in the figure 3 hereafter : 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ |L M S E D C X R| +-+-+-+-+-+-+-+-+ Figure 3 : Flags field format for Sub-Type values 1-2. The bits of the Flags field are interpreted as below: L = Length included; Urien & All Informational - Expires June 2004 5 EAP-SSC Secured Smart Card Channel December 2003 M = More fragments; S = EAP-SSC Start; E = EAP-SSC End; D = EAP-SSC Digest; C = EAP-SSC Ciphered payload; X = EAP-SSC Sequence of X.509 Certificate(s); R = Reserved. Bits L, M and S look like that described in EAP-TLS (RFC 2716). The L bit (Length included) is set to indicate the presence of the three octets EAP-SSC Message Length field, and MUST be set for the first fragment of a fragmented EAP-SSC message or set of messages. The M bit (More fragments) is set on all but last fragment of a fragmented EAP-SSC message. It means that the contents of this EAP-SSC packet is not the last part of the message. When an EAP-SSC Supplicant receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type=EAP-SSC- Type and no data. This serves as a fragment Acknowledgement. The Authentication Server MUST wait until it receives the EAP-Response before sending another fragment. In order to prevent errors in processing of fragments, the Authentication Server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the Supplicant MUST include this Identifier value in the fragment Acknowledgement contained within the EAP-Response. Retransmitted fragments will contain the same Identifier value. Similarly, when the Authentication Server receives an EAP-Response with the M bit set, it MUST respond with an EAP-Request with EAP-Type=EAP- SSC-Type and no data. This serves as a fragment Acknowledgement. The EAP Supplicant MUST wait until it receives the EAP-Request before sending another fragment. In order to prevent errors in the processing of fragments, the Authentication Server MUST increment the Identifier value for each fragment Acknowledgement contained within an EAP- Request, and the Supplicant MUST include this same Identifier value in the subsequent fragment contained within an EAP-Response. The S bit (EAP-SSC Start) is set only within the EAP-SSC/Start message sent from the Authentication Server to the Supplicant. This differentiates the EAP-SSC/Start message from the others. The E bit (EAP-SSC End) is set in an EAP-SSC/End message sent from the Authentication Server to the Supplicant. This differentiates the EAP- SSC/End message from other messages. The D bit (EAP-SSC Digest) is set if an EAP-SSC message is ended with a message digest. The C bit (EAP-SSC Ciphered payload) is set in an EAP-SSC message to mean the payload is enciphered. The data encryption algorithm used is by default the Triple Data Encryption Algorithm (TDEA as described in ANSI X9.52) using CBC mode with keying option 2 for bundle (K1, K2, K3) where K1 and K2 are independent keys and K3=K1. The X bit (EAP-SSC Sequence of X.509 Certificate(s)) is set if in an EAP-SSC message the payload contains a sequence of X.509 Certificate(s). The R bit means "Reserved" and will be kept at 0 until future usages have been specified. Urien & All Informational - Expires June 2004 6 EAP-SSC Secured Smart Card Channel December 2003 3.2.4 Message Length field The EAP-SSC Message Length field is three octets, and is present only if the L bit is set. This field value provides the total length of the EAP-SSC message or set of messages that is being fragmented. 3.2.5 Payload field The Payload field is expected to receive the body of the message, depending on the Sub-Type and the Flags fields 3.2.6 Digest field The Digest field is present in the EAP-SSC packet only if the D bit is set in the Flags field. The Digest field has 160-bits or 20-bytes length and terminates the EAP-SSC packet. It corresponds to the result of the computation of the message digest, using Secure Hash Algorithm (SHA-1) applied generally to the concatenation of many values. Each time the digest is computed, all values that are used in input should be clearly specified. 4 Setting up the Secured Smart Card Channel It is assumed to be in an environment where to access to the services offered by the network, a Supplicant must access to an Authenticator (Access Point) which will use an Authentication Server (RADIUS Server) to check its capacities. Between the Supplicant and the Authenticator it is assumed to use EAPOL (EAP over LAN) and between the Authenticator and the Authentication Server it is assumed to use EAPOR (EAP over RADIUS). According to the EAP authentication exchange, the Authenticator sends generally a Request for identity to authenticate the Supplicant. In response to this packet, the Supplicant sends a Response packet containing this identity which is forwarded to the Authentication Server. Since this moment and only in the case this response is valid, the Authentication Server will attempt to set up a secured channel with the Supplicant through the Authenticator. In the table 1 are listed operators and functions used to calculate values used to fill some EAP-SSC packet fields. +-------------------+------------------------------------------+ | Operator/function | Meaning | +-------------------+------------------------------------------+ | a XOR b | bit-wise logical "exclusive OR" between | | | two values a and b | +-------------------+------------------------------------------+ | a | b | Concatenation of the right value b to | | | the left value a | +-------------------+------------------------------------------+ | a MOD b | Remainder of the integer division of a | | | by b | +-------------------+------------------------------------------+ | x*y | x times y | +-------------------+------------------------------------------+ | x**n | Equivalent to x*x*x...*x , n times | +-------------------+------------------------------------------+ | D(msg) | Computation of the digest of the message + | | msg using by default SHA-1 algorithm | +-------------------+------------------------------------------+ Table 1 : Operators and functions used for some EAP-SSC fields description. Urien & All Informational - Expires June 2004 7 EAP-SSC Secured Smart Card Channel December 2003 For setting up this Secured Smart Card Channel two steps can be distinguished: firstly the calculation of the sessionĘs key, and secondly the validation of this computed sessionĘs key. Each one of these phases corresponds with an exchange between the Supplicant and the Authentication Server. 4.1 SessionĘs Key (SK) calculation 4.1.1 Overview As already indicated higher, this phase follows the receipt by the Authentication Server of the forwarded EAP-Response/Identity packet from the Authenticator. In this packet is supposed encapsulated a packet of EAP-SSC type. It is according to the value of its Sub-Type field that will depend the components to be used to calculate the sessionĘs key SK. According to each one of these two key exchange contexts, the mode of calculation of the sessionĘs key is detailed in this document. 4.1.2 SessionĘs key calculation, Symmetric case When the Authentication Server receives the valid EAP-Response/Identity packet from the Authenticator, it generates a random positive number r1 of 160 bits (20 bytes) length (the high order bit of r1 is set to 0). This r1 number is then packed in plaintext, low order byte first, in an EAPOR-Request/EAP-SSC/Start packet which is sent to the Supplicant according to the format presented in the figure 4 hereafter: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=0x01 |Identifier=0x01| Length=0x1B | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP-SSC-Type | Sub-Type=0x01 | Flags=0x20 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . . . r1 (20 bytes, low order byte first) . + +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 : EAP-SSC first packet format sent by the Authentication Server in a symmetric key exchange model. When the Authenticator receives the EAPOR-Request/EAP-SSC/Start packet, it MUST modify and transmit it according to the packets format supported by the communication between him and the Supplicant; as a result, it is an EAPOL-Request/EAP-SSC/Start packet which is transmitted to the Supplicant. With the reception of this packet, the Supplicant recovers the value of r1 sent by the Authentication Server. Similarly to the Authentication Server, the Supplicant generates a random positive number r2 of 160 bits length (the high order bit of r2 is set to 0) which is then used to compute the value of Z as follows: Z = r2 XOR D(r1 | s), Urien & All Informational - Expires June 2004 8 EAP-SSC Secured Smart Card Channel December 2003 with the value s corresponding to the secret shared by the Authentication Server and the Supplicant, value which is for the Supplicant supposed to be kept inside the Smart Card. Since this moment, the Supplicant is able to compute, using the triplet (r1, r2, s), the sessionĘs key SK as follows: SK = D(r1 | r2 | s). Then, the value of Z is packed, low order byte first, by the Supplicant in an EAPOL-Response/EAP-SSC packet which is addressed to the Authentication Server via the Authenticator as it is shown in the figure 5 below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=0x02 |Identifier=0x01| Length=0x1B | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP-SSC-Type | Sub-Type=0x01 | Flags=0x00 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . . . Z = r2 XOR D(r1 | s)(20 bytes, low order byte first) . + +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 : EAP-SSC first response packet format sent by the Supplicant to the Authentication Server in a symmetric key exchange model. Authenticator that receives the EAPOL-Response/EAP-SSC packet transforms it into an EAPOR-Response/EAP-SSC packet and forwards it to the Authentication Server. At the arrival of the EAPOR-Response/EAP-SSC packet to the Authentication Server, this one recovers the value of Z. Because of knowing r1 and s, the Authentication Server is able to calculate the message digest D(r1 | s) and thus to find back the r2 number. The possession of the triplet (r1, r2, s) allows the Authentication Server to calculate on its own side the sessionĘs key as the Supplicant has done: it is the end of the EAP-SSC sessionĘs key calculation phase in the symmetrical key exchange model. Note 1 : Conditions and means which are employed to share and distribute in safety the secret s between the Authentication Server and the Smart Card are outside of the scope of this draft. It is also supposed to have enough space and processing capabilities to compute SK in the Smart Card. To illustrate the exchange during this sessionĘs key calculation phase, the figure 6 below is presented. In thick lines appear all exchanges carried in EAPOL packets, and in broken lines EAPOR packets that use RADIUS. Supplicant Authenticator Authentication Server <========================= - - - - - - EAPOR-Request/ EAP-SSC/Start with r1. Modification from EAPOR format to EAPOL format. EAPOL-Response/EAP-SSC with (r2 XOR D(r1 | s)) Urien & All Informational - Expires June 2004 9 EAP-SSC Secured Smart Card Channel December 2003 ========================== - - - - - - - - - - > Modification from EAPOL format to EAPOR format. SK = D(r1 | r2 | s) SK = D(r1 | r2 | s) is Computed. is Computed. Figure 6 : Example of the sessionĘs key calculation in the context of encryption using secret key. 4.1.3 SessionĘs key calculation, Asymmetric case In the context of enciphering using public key, instead of using secret keys, one will make use of certificates rather, electronic documents that carry the public keys and additional data for encryption and deciphering. When the Authentication Server possesses the certificate of the Supplicant, and vice versa the Supplicant has the certificate of the Authentication Server, they can bypass the exchange of the certificates, and in this case C1 and C2 that mean exchanged certificates in this document are empty. In own way of illustration, we give the following figure 7 in which, similarly to the precedent figure, thick lines are used for all exchanges carried in EAPOL packets, and broken lines for EAPOR packets. Supplicant Authenticator Authentication Server <======================== - - - - - - EAPOR-Request/EAP-SSC /Start with C1 and r1 Modification from EAPOR format to EAPOL format. EAPOL-Response/EAP-SSC with C2, r2**K1public, ====== - - - - - - - - - - - > and D0**K2private. Modification from EAPOL format to EAPOR format. SK = D(r1 | r2) SK = D(r1 | r2) is computed. is Computed. Figure 7 : Example of the sessionĘs key calculation in the context of encryption using public key. At the beginning of this phase, the Authentication Server generates a random positive number r1 which length depends only on him (the high order byte of r1 is set to 0). This r1 number and the optional sequence of certificates named C1 belonging to the Authentication Server are coded in BER ASN.1 [12] format and packed in plaintext in an EAPOR- Request/EAP-SSC/Start packet which is sent to the Supplicant. This packet format is illustrated in the figure 8 hereafter. Urien & All Informational - Expires June 2004 10 EAP-SSC Secured Smart Card Channel December 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=0x01 |Identifier=0x01| Length = yy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP-SSC-Type | Sub-Type=0x02 | Flags = zz | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . Optional sequence of certificates C1 . . Integer r1 . + +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 : EAP-SSC first request packet format sent by the Authentication Server in an asymmetric key exchange model. In a situation where there is no need to exchange certificates between the Authentication Server and the Supplicant (for example the Supplicant has inside the Smart Card the certificate of the Authentication Server and the Authentication Server stores the certificate of the Supplicant), the payload of this packet will contain exclusively the random positive number r1. Its length will determine the length yy of the packet, the length of the message, and values of bits L (Length included) and M (More fragment) in Flags field value zz in which the bit S (start) will be set. In other cases, a sequence of certificates and the random number r1 are sent to the Supplicant by the Authentication Server and these data will determine the length yy of the packet, the length of the message, and values of bits L (Length included) and M (More fragment) in Flags field value zz in which the S (start) and X (X.509 certificate(s) included) bits will be set. When the Authenticator receives the EAPOR-Request/EAP-SSC/Start packet, it MUST modify and transmit it according to the packets format supported by the communication between him and the Supplicant; as a result, it is an EAPOL-Request/EAP-SSC/Start packet which is transmitted to the Supplicant. When this packet reaches to the Supplicant, the random positive number r1 and the optional chain of certificates C1 are extracted. So, the Supplicant is able to recover the public key named K1public of the sender of the message and the corresponding modulo base named Modulo1. Similarly to the Authentication Server, the Supplicant will generate a random positive number r2 which length is variable (but with always the high order byte set to 0) and will compute two values U and V as follows: U = (r2 ** K1public) MOD Modulo1 V = (D0 ** K2private) MOD Modulo2 with: D0 = D(Code | Identifier | Length | EAP-Type | Sub-Type | Flags | Optional Certificates C2 | value U in BER ASN.1 format). In fact, D0 corresponds to the digest of the concatenation of all fields preceding it in the packet. The values U and V correspond to the encryption respectively of the random positive number r2 with the public key of the Authentication Server, and the message digest D0 with the private key of the Supplicant. Urien & All Informational - Expires June 2004 11 EAP-SSC Secured Smart Card Channel December 2003 Since this moment, the Supplicant is able to compute, using the couple (r1, r2) , the sessionĘs key SK as SK = D(r1 | r2). Then, the SupplicantĘs optional sequence of certificates C2 and the computed values U and V are coded in BER ASN.1 format and packed by the Supplicant in an EAPOL-Response/EAP-SSC packet which is addressed to the Authentication Server via the Authenticator. In the further figure 9 is represented the format of the first response packet sent from the Supplicant to the Authentication Server via the Authenticator. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=0x02 |Identifier=0x01| Length = yĘyĘ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP-SSC-Type | Sub-Type=0x02 | Flags = zĘzĘ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . Optional sequence of certificates C2 . . U = r2**K1public MOD Modulo1 (integer) . + V = D0**K2private MOD Modulo2 (integer) +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 : EAP-SSC first packet format sent by the Authenticator in an asymmetric key exchange model. The usage of a sequence of certificates and the values of Modulo1 and Modulo2 will determine the packet Length yĘyĘ and the values of L, M and X bits in the Flags field value zĘzĘ. Authenticator that receives the EAPOL-Response/EAP-SSC packet transforms it into an EAPOR-Response/EAP-SSC packet and forwards it to the Authentication Server. When this EAPOR-Response/EAP-SSC packet will reach to the Authentication Server, this one will extract the optional chain of certificates C2 from which it will be able to discover the public key K2public and the modulo base named Modulo2 of this sender. Using these two values, the Authentication Server will also be able to recover the value of D0 and check it with that it can compute locally from the received packet. If this comparison of digests is successful, the Authentication Server will continue with the extraction of the random positive value r2 from U by using its private key K1private and its modulo base Modulo1. Otherwise, the Authentication Server will silently discard this packet. With the couple (r1, r2) the Authentication Server is also capable to compute the sessionĘs key SK = D(r1 | r2), ending this phase. Note 2 : Before using data from certificates, it is assumed their validity and authenticity have been checked. And this verification aspect of the certificate is outside of the scope of this draft. 4.2 SessionĘs key validation Succeeding directly to the phase of the sessionĘs key calculation both on the side of the Authentication Server and the side of the Supplicant, the validation phase takes place. Its purpose is meanly to verify that the two peers actually have computed a same value of the sessionĘs key SK, and so, will confirm/infirm the presence of a secured Urien & All Informational - Expires June 2004 12 EAP-SSC Secured Smart Card Channel December 2003 channel between the Supplicant and the Authentication Server. There is no difference between the way this phase is proceeded in a symmetrical key exchange context and an asymmetrical key exchange context. Initiated by the Authentication Server, an EAPOR-Request/EAP-SSC packet is sent via the Authenticator to the Supplicant. The characteristic of this packet is to contain a message named M1 which may be empty but always ended with a message digest D1 which is computed as D1 = D(M1 | SK), according to the format presented in the followed figure 10. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=0x01 |Identifier=0x02| Length = y"y" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP-SSC-TYPE | Sub-Type = n | Flags=0x08 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . M1 . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | D1(M1, SK) (20 bytes) | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10 : EAP-SSC 2nd packet format sent by the Authentication Server to the Supplicant. Generally, the Length field value y"y" of the packet will depend on the length of the message M1. Sub-Type field value n will be either 1 for symmetric key exchange context, or 2 for asymmetric key exchange context. The Flags field value shows the bit D (Digest) is set. With the reception of the EAPOR-Request/EAP-SSC packet by the Authenticator, this one transforms it in a packet with EAPOL format; it is thus an EAPOL-Request/EAP-SSC packet which is finally transmitted to the Supplicant. When the Supplicant receives this packet, it extracts the message digest D1 sent by the Authentication Server. It checks the received D1 to see if itĘs equal to the message digest that is computed locally by using its sessionĘs key SK. When this comparison failed, the Supplicant silently discards this packet. Otherwise, the Authentication Server has been correctly authenticated and the Supplicant will continue by computing a new message digest D2 according to the formula D2 = D(M2 | D1 | SK), where M2 corresponds to a message sent in response to M1. M2 may be a null length message. M2 with D2 will be packed in an EAPOL- Response/EAP-SSC packet as presented in the figure 11 and conveyed to the Authentication Server via the Authenticator. 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 Urien & All Informational - Expires June 2004 13 EAP-SSC Secured Smart Card Channel December 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=0x02 |Identifier=0x02| Length = zĘzĘ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP-SSC-TYPE | Sub-Type = n | Flags=0x08 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . M2 . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | D2(M2, D1, SK) (20 bytes) | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11 : EAP-SSC 2nd packet format sent from the Supplicant to the Authentication Server. Similarly to the previous packet, the Length field value zĘzĘ of the packet will depend on the length of the message M2. Sub-Type field value n will be either 1 or 2 depending on the key exchange context and the D bit will be set in the Flags field. The Authenticator that receives the EAPOL-Response/EAP-SSC packet, like in the sessionĘs key calculation phase, transforms it into an EAPOR- Response/EAP-SSC packet and forwards it. Finally, the EAPOR-Response/EAP-SSC packet is received by the Authentication Server which extracts the message digest named D2(receipt) from it. As knowing SK and D1 the Authentication Server locally will calculate its own message digest named D2 (local) and will compare it with D2(receipt). If they are not equal, the Authentication Server silently discards the packet. Otherwise, one can affirm that the Supplicant shares indeed the same sessionĘs key with the Authentication Server: sessionĘs key SK has been validated between the Supplicant and the Authentication Server. Supplicant Authenticator Authentication Server an SK is available an SK is available EAPOR-Request/EAP-SSC <===================== - - - with M1 and D1 = D(M1 | SK) Modification from EAPOR format to EAPOL format EAPOL-Response/EAP-SSC with M2 and ============== - - - - - - - - - - - > D2=D(M2 | D1 | SK) Modification from EAPOL format to EAPOR format SK and D2 are available. SK and D2 are available. For any i > = 3 Di can be For any i > = 3 Di can be computed as D(Mi | Di-1 | SK). computed as D(Mi | Di-1 | SK). Figure 12 : Exchanges during the sessionĘs key validation. Urien & All Informational - Expires June 2004 14 EAP-SSC Secured Smart Card Channel December 2003 In the figure 12 is shown an example of exchange during the sessionĘs key validation phase. 5 Secure Channel Messages exchanges Since the completion of the sessionĘs key calculation, all messages sent from the Authentication Server to the Supplicant and vice versa are appended with a digital digest value Di deduced from the sessionĘs key SK, the message Mi to send and the digest Di-1 of the latter step as presented hereafter: D1 = D(M1 | SK); For any step i>1, Di = D(Mi | Di-1 | SK), with SK computed from (r1, r2, s) triplet in secret key encryption context, and only from (r1, r2) couple otherwise. At least three messages M1, M2 and Mf (f equals 3 here) are exchanged: * M1 a request message from the Authentication Server or a null length message; * M2 a response message from the Supplicant or a null length message; * Mf a final message originated by the Authentication Server for terminating the exchanges on the secured channel. The EAP-SSC packet containing this last message as presented in the figure 13 will have in its Flags field the E (End) bit set. As this message is also ended with a digest, all rogue packets with E bit set will have no effect on the Supplicant. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=0x03 |Identifier=0x03| Length = y"y" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP-SSC-TYPE | Sub-Type = n | Flags=0x18 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . Mf . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | Df(Mf, Df-1, SK) (20 bytes) | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13 : EAP-SSC final packet format sent by the Authentication Server to the Supplicant. For this packet also, the Length y"y" will depend on the length of the message Mf. Sub-Type field value n will be either 1 or 2 depending on the key exchange context. In the Flags field the E (End) and D (Digest) bits will be set. Urien & All Informational - Expires June 2004 15 EAP-SSC Secured Smart Card Channel December 2003 Between message M2 and message Mf, the Authentication Server and the Supplicant can continue to exchange messages, by taking care to end each Mi message with the required message digest Di. 6 Segmentation issue Considering the public key exchange context, it will be frequent to have in the payload of EAP-SSC packet a sequence of certificates, either sent to the Authentication Server or to the Supplicant. However, a certificate size may be near a kilo-byte and the size of EAP packet limited to 240 bytes. So the issue of the segmentation will be to manage long EAP-SSC message. The presence of the Message length field and the M (More segment) bit of Flags field can help to do it. 7 LDAP messages If it is assumed a Smart Card can contain inside many directories, the capability to establish a secure communication with an Authentication Server can be used to embed commands for LDAP oriented data-base management (creation, reading, writing, deletion, etc.) A choice of a particular value of Sub-Type field can mean the payload contains LDAP commands. This Sub-Type value can be completed by special format of the Flags field where a particular bit may mean that commands are in ASN.1 format and so on. 8 Messages encryption One of the best ways to assure confidentiality of the exchanged messages between the Authentication Server and the Smart Card is to use encryption. This capability is basically assured by setting up the C (Ciphering) bit of the Flags field which means the payload in the packet has been enciphered. The cryptographic algorithm by default used to encrypt the payload is the Triple Data Encryption Algorithm (TDEA) as described in ANSI X9.52 [13] [14], according to the EDE scheme (Encryption-Decryption-Encryption) in CBC (Cipher Block Chaining) with keying triplet (K1, K2, K3), where K1 and K2 are independent keys when K1 and K3 are identical keys. For this reason, two important features must be specified : first the cryptographic keys that are used and shared by the sender and the receiver of the message, and secondly the way to assure message padding if necessary. As the cryptographic key controls the encryption process, the same key must be also used during the decryption process to assure that the receiver will obtain the original data used before encryption. Since cryptographic security depends on the secrecy of the keys, it is important to avoid their transmission during exchanges, to prevent spoofing attacks. So it is decided to produce dynamically these cryptographic keys in each side of the exchange between the Authentication Server and the Smart Card. And the materials used to produce these keys are first the Session Key (SK) which is set up after the sessionĘs key calculation phase and secondly a counter corresponding to the Identifier field value. Let i be the value of the Identifier field of the packet to be sent and in which the payload must be enciphered. Let us consider SK as a 160- bits integer where bits are numbered from 0 for the lowest bit and 159 for the highest bit. The index f(i) whose value lies between 0 and 159 represents the number of circular right shifts (binary rotations) to Urien & All Informational - Expires June 2004 16 EAP-SSC Secured Smart Card Channel December 2003 apply to SK, before getting from this result the lowest 112 bits that will correspond to the cryptographic key at a given time by the Triple DES algorithm. f(x) is a determinist well known function which is by default chosen as ((3391*x) MOD 160)). The way to obtain a cryptographic key is illustrated by the figure 14. It is also assumed for the security improvement that the Authentication Server is the only one entity allowed to start encryption. When the Smart Card receive an enciphered packet, it must respond with an enciphered packet too. And when one side of the exchange receives an encrypted packet it canĘt decrypt, it silently discards it. f(i) | |<----------------------> v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | |y . . . .| |. . x| | | | | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 1 0 0 0 0 5 5 1 1 0 0 9 8 7 6 5 4 3 2 1 0 . . . . . 6 . . . . . 0 9 8 7 6 5 4 3 2 1 0 <------- SK material before circular right shifting ------------> cryptographic key (112 bits) |<--------------------------------------->| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | | | | | | | | | | | |y . . . .| |. . x| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 1 0 0 0 0 5 5 1 1 0 0 9 8 7 6 5 4 3 2 1 0 . . . . . 6 . . . . . 0 9 8 7 6 5 4 3 2 1 0 <-------- SK material after circular right shifting ------------> Figure 14 : EAP-SSC basic encryption keys calculation. Since the CBC mode is a block method of encryption which operates on 64-bits data blocks, it is important to take care of the partial data blocks (ending blocks of the messages that are less than 64 bits long). So it is decided to pad these final partial blocks before processing their encryption. The following method of padding is used. The bytes of a final partial block is left justified and completed to 8-bytes block with padding bytes. The value of the padding byte depends on the value of the last byte of the original message and corresponds to its complement. As the padding message must include a special indicator for the entity in charge of the decryption, even final complete block will be followed by a block made of padding bytes only. So, after the deciphering operation of the last block of a message, the decryption entity must systematically reverse padding process by removing all padding bytes (up to 8 identical bytes sometimes) and producing the original plain text. The figure 15 gives an illustration of this padding method. Urien & All Informational - Expires June 2004 17 EAP-SSC Secured Smart Card Channel December 2003 Original message is a 8-bytes multiple length. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |h e l l o w o r l d s t o p| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 68656c6c6f20776f726c642073746f70 <-- ASCII code of characters Splitting blocks +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |h e l l o w o| |r l d s t o p| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 68656c6c6f20776f 726c642073746f70 <-- ASCII code of characters padding block +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |h e l l o w o| |r l d s t o p| |p'p'p'p'p'p'p'p'| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 68656c6c6f20776f 726c642073746f70 8f8f8f8f8f8f8f8f Original message is not a 8-bytes multiple length. +-+-+-+-+-+-+-+-+-+-+-+ |h e l l o w o r l d| +-+-+-+-+-+-+-+-+-+-+-+ 68656c6c6f20776f726c64 <-- ASCII code of characters Splitting and padding blocks +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |h e l l o w o| |r l d p'p'p'p'p'| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 68656c6c6f20776f 726c649b9b9b9b9b <-- ASCII code of characters with p' = complement(p), which means that for each bit set in the "p" byte, its corresponding bit is changed to zero in "p'", and each bit zero in the "p" is associated to a set bit in the padding byte "p'". Figure 15 : Examples of padding before EAP-SSC message encryption. 9 Examples of traces with plain text payload This section of the document provides two examples of results of a simulation of the running of two sessions, the first session associated to a symmetrical key exchange context, and the second to a public key exchange context. All computed values used to produce the five packets which are exchanged in each case are presented with hereafter assumptions: - EAP-SSC-Type equal 255 (hexadecimal FF); - Starting Identifier equals 165 (hexadecimal A5); - The payload is not enciphered. 9.1 Traces in a symmetrical key exchange context //* value of the shared secret s 83D972D101F40973DEC8E32068B1DE581641EA76 //******** Beginning of the 1st packet of the exchange ********** Urien & All Informational - Expires June 2004 18 EAP-SSC Secured Smart Card Channel December 2003 //*********** sent by the Authentication Server (AS) ************ 01 A5 00 1B FF 01 20 ; header ^ ^ ----- ^ ^ ^ | | ^ | | | | | | | | +----- Flags field with S (Start) bit set | | | | +---- Sub-Type field set for symmetrical case | | | +----- EAP-SSC-Type | | +------- Packet Length field set to 27 | +------- Identifier field +------- Code Field set for EAP-Request packet BDD99CB2FDABDC5995521D3F4D7241BBA6A96E5D ; value of r1 (20 bytes) //******************* End of the 1rst packet ******************** //* value of r2 (20 bytes) generated by the Smart Card E72D5787D1C037E1DE3CFE63DCF5DF8DF2523693 //* value of D(r1 | s) A575616DE4EB41230E39B28A94BB86039E27F8C9 //******** Beginning of the 2nd packet of the exchange ********** //************* sent by the Smart Card to the AS **************** 02 A5 00 1B FF 01 00 ; header ^ ^ ----- ^ ^ ^ | | ^ | | | | | | | | +----- Flags field | | | | +---- Sub-Type field set for symmetrical case | | | +----- EAP-SSC-Type | | +------- Packet Length field set to 27 | +------- Identifier field equals to that of the request packet +------- Code Field set for EAP-Response packet 425836EA352B76C2D0054CE9484E598E6C75CE5A ; Z = r2 XOR D(r1 | s) //******************* End of the 2nd packet ********************* //* value of the computed SessionĘs Key SK AB5AFE7AC13CEE477BEACE3A5178AD9D7BD7D374 //******** Beginning of the 3rd packet of the exchange ********** //************* sent by the AS to the Smart Card **************** 01 A6 00 20 FF 01 08 ; header ^ ^ ----- ^ ^ ^ | | ^ | | | | | | | | +----- Flags field with D (Digest) bit set | | | | +---- Sub-Type field set for symmetrical case | | | +----- EAP-SSC-Type | | +------- Packet Length field set to 32 | +------- Identifier field has been incremented to 166 +------- Code Field set for EAP-Request packet 68 65 6C 6C 6F ; M1="hello" 22F182938CBA24E4E49D2B5E9EA3B53321DE84FD ; D1 = D("hello" | SK) //******************* End of the 3rd packet ********************* //******** Beginning of the 4th packet of the exchange ********** //************* sent by the Smart Card to the AS **************** 02 A6 00 20 FF 01 08 ; header ^ ^ ----- ^ ^ ^ | | ^ | | | | | | | | +----- Flags field with D (Digest) bit set | | | | +---- Sub-Type field set for symmetrical case | | | +----- EAP-SSC-Type | | +------- Packet Length field set to 32 | +------- Identifier field equals to that of the request packet +------- Code Field set for EAP-Response packet Urien & All Informational - Expires June 2004 19 EAP-SSC Secured Smart Card Channel December 2003 77 6F 72 6C 64 ; M2="world" AB10AB506D923CE0BC60221ACF503D6338C1EDA2 ; D2=D("world" | D1 | SK) //******************* End of the 4th packet ********************* //******** Beginning of the 5th packet of the exchange ********** //************* sent by the AS (EAP-Success/End) **************** 03 A7 00 1F FF 01 18 ; header ^ ^ ----- ^ ^ ^ | | ^ | | | | | | | | +----- Flags field with D (Digest) and E (End) | | | | | bits set | | | | +---- Sub-Type field set for symmetrical case | | | +----- EAP-SSC-Type | | +------- Packet Length field set to 31 | +------- Identifier field has been incremented to 167 +------- Code Field set for EAP-Success packet 73 74 6F 70 ; M3="stop" E69D06BA33DF2799B436D65A348F33840B332810 ; D3=D("stop" | D2 | SK) //******************* End of the 5th packet ********************* 9.2 Traces in an asymmetrical key exchange context We assume the Authentication Server knows the public key of the Smart Card, and the public key of the Authentication Server is also known by the Smart Card. For these reasons, fields used by certificates C1 and C2 in exchanged packets are empty. //** First Pair-wise-key used by the Authentication Server //* Value of Modulo1 - Integer 129 bytes 02 81 81 00EE9D84FB3D70CD3CF145BDB8D1D7580BDB917149D44EE09C6E8409853E7D68 5A7C61F840B687EC0F841FEDBCEA6FBBD872783C43CA04AEA56956BD607AAB38 739E629C6FAE2D34B69FFD3D722BE41719CFA5122B50D7821A4FF69DB5E6839D 5938D8D8FD830488342AA5A266A45CD8C1AE32E59B66EE1FFA65DEBD6235824B 21 //* Value of K1public - Integer = 3 02 01 03 //* Value of K1private - Integer 129 bytes 02 81 81 009F13ADFCD3A088D34B83D3D08BE4E55D3D0BA0DBE2DF406849AD5BAE29A8F0 3C52EBFAD5CF05480A581549289C4A7D3AF6FAD2D7DC031F18F0E47E4051C77A F6754030B429325864665ECE80839E26AAE039CE642E8253A7E4074BC934D109 8FC5FA3F6D9985251A3123BAB9AEA498F81FE5EE4407195757FED591D09F5D10 CB //** Second Pair-wise-key used by the Smart Card //* Value of Modulo2 - Integer 65 bytes 02 41 00B7C2DF803986F6F4DFBA2E104FC5DE0F8DC50ABE713DB9AA2B78387996DCC6 437FFA8B24CD657FAEEE02082EA01553E2DC0A68A5FD5891AAEF78C2489CAB50 C1 //* Value of K2public - Integer = 3 02 01 03 //* Value of K2private - Integer 64 bytes 02 40 7A81EA557BAF4F4DEA7C1EB58A83E95FB3D8B1D44B7E7BC6C7A57AFBB9E8842B DD5FA9723EC5BF7A9CB387AF255583620B98FE5F0020EE72E24BB429D4BBCACB //******** Beginning of the 1st packet of the exchange ********* //*********** sent by the Authentication Server (AS) *********** 01 A5 00 2D FF 02 20 ; header Urien & All Informational - Expires June 2004 20 EAP-SSC Secured Smart Card Channel December 2003 ^ ^ ----- ^ ^ ^ | | ^ | | | | | | | | +----- Flags field with S (Start) bit set | | | | +---- Sub-Type field set for asymmetrical case | | | +----- EAP-SSC-Type | | +------- Packet Length field set to 45 | +------- Identifier field +------- Code Field set for EAP-Request packet 02 84 00 00 00 20 ; ASN.1 header of the integer r1 //* Value of r1 on 32 octets (256 bits) 005A9B7B1ABDF0A329B3AB16E5F8933154E33C2C4ADD82F4DD2753257FF62ADC //******************* End of the 1rst packet ******************* //* Value of r2 on 128 octets (1024 bits) 006696D8F9847CAC6FD072E68E7339B8A96BCD4E7D5E2C2B69CF802F79F584EA AEB85C19D59986E285CCBF86EE4AEB5B0061909165A0B6E3CDA8AA21704C363B 7475F198E22320CDF3B86F40B46EC879482718C5DF242A72A081E674C763469B B55E6B5946FF5BF7DB82E22194EC4F4C177C067A980A4B945DED75B0C8B23F19 //* Value of U on 128 bytes (1024 bits) equals to the encryption //* of r2 with the public key K1public of the AS 7E36D476944C29467915734360D647D6A8923043B727548495A265B7A38CACBE 0CEF55DF16911AA8A63BFB55D5262D14A1D4FC82B0DF011AD61FD243916C4682 A73E647E1269785EECEE414BCFE43660E107D120E30CED09151D884D15B0BA94 17F038955AF4B68621AF0EC3E38DBCCB0827961813B26123FE001DB0E0316211 //* Value of D0 on 20 bytes computed as the digest of the //* concatenation of fields from Code field to integer value U //* coded in the packet by the Smart Card 9E7EFE6B9C60428CC61C8798C8F4FE4835BA0861 //* Value of V on 64 bytes (512 bits) equals to the encryption //* of D0 with the private key K2private of the Smart Card 3A95A34B98F5E009FAE2ECE3F836DFEBB73EEC8B89F733C02F74EBB236AB6151 5D003228F355877C94AFDAAADEC5C47F236F09FE1D8E651FAFE757F064292B73 //******** Beginning of the 2nd packet of the exchange ********* //*************** sent by the Smart Card to the AS ************* 02 A5 00 D3 FF 02 00 ; header ^ ^ ----- ^ ^ ^ | | ^ | | | | | | | | +----- Flags field | | | | +---- Sub-Type field set for asymmetrical case | | | +----- EAP-SSC-Type | | +------- Packet Length field set to 211 | +------- Identifier field +------- Code Field set for EAP-Response packet 02 84 00 00 00 80 ; ASN.1 header of the integer U value ; coded on the 128 bytes below 7E36D476944C29467915734360D647D6A8923043B727548495A265B7A38CACBE 0CEF55DF16911AA8A63BFB55D5262D14A1D4FC82B0DF011AD61FD243916C4682 A73E647E1269785EECEE414BCFE43660E107D120E30CED09151D884D15B0BA94 17F038955AF4B68621AF0EC3E38DBCCB0827961813B26123FE001DB0E0316211 02 84 00 00 00 40; ASN.1 header of the integer V value ; coded on the 64 bytes below 3A95A34B98F5E009FAE2ECE3F836DFEBB73EEC8B89F733C02F74EBB236AB6151 5D003228F355877C94AFDAAADEC5C47F236F09FE1D8E651FAFE757F064292B73 //******************* End of the 2nd packet ******************** Urien & All Informational - Expires June 2004 21 EAP-SSC Secured Smart Card Channel December 2003 //* value of the SessionĘs Key SK 3B4C5E8CD72D723A6CC971612DFFED0EB1E8B514 //* value of D1=D("hello" | SK) 772EC3BD82C07C9A8F06FE006ED779EA7AAB8B77 //******** Beginning of the 3rd packet of the exchange ********* //************** sent by the AS to the Smart Card ************** 01 A6 00 20 FF 02 08 ^ ^ ----- ^ ^ ^ | | ^ | | | | | | | | +----- Flags field with D (Digest) bit set | | | | +---- Sub-Type field set for asymmetrical case | | | +----- EAP-SSC-Type | | +------- Packet Length field set to 32 | +------- Identifier field has been incremented to 166 +------- Code Field set for EAP-Request packet 68 65 6C 6C 6F ; M1="hello" 772EC3BD82C07C9A8F06FE006ED779EA7AAB8B77 ; D1=D("hello" | SK) //******************* End of the 3rd packet ******************** //* value of D2=D("world" | D1 | SK) CB2A67FAEB44BBC841E99ECAD6C8B25B2FCB3122 //******** Beginning of the 4th packet of the exchange ********* //************** sent by the Smart Card to the AS ************** 02 A6 00 20 FF 02 08 ^ ^ ----- ^ ^ ^ | | ^ | | | | | | | | +----- Flags field with D (Digest) bit set | | | | +---- Sub-Type field set for asymmetrical case | | | +----- EAP-SSC-Type | | +------- Packet Length field set to 32 | +------- Identifier field is the same as for request packet +------- Code Field set for EAP-Response packet 77 6F 72 6C 64 ; M2="world" CB2A67FAEB44BBC841E99ECAD6C8B25B2FCB3122 ; D2=D("world" | D1 | SK) //******************* End of the 4th packet ******************** //* value of D3=D("stop" | D2 | SK) D5ACB12A9F74B2E09B5CB1788D1EBE8AE6E8027C //******** Beginning of the 5th packet of the exchange ********* //************** sent by the AS (EAP-Success/End) ************** 03 A7 00 1F FF 02 18 ^ ^ ----- ^ ^ ^ | | ^ | | | | | | | | +----- Flags field with E (End) and D (Digest) | | | | | bit set | | | | +---- Sub-Type field set for asymmetrical case | | | +----- EAP-SSC-Type | | +------- Packet Length field set to 31 | +------- Identifier field has been incremented +------- Code Field set for EAP-Success packet 73 74 6F 70 ; M3="stop" D5ACB12A9F74B2E09B5CB1788D1EBE8AE6E8027C ; D3=D("stop" | D2 | SK) //******************* End of the 4th packet ******************** Urien & All Informational - Expires June 2004 22 EAP-SSC Secured Smart Card Channel December 2003 10 Intellectual Property Right Notice To be specify according to the author and participant. 11 References [1] H. Andersson, S. Josefsson, G. Zorn, D. Simon, A. Palekar, "Protected EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap- 05.txt, work-in-progress, September 2002. (INFORMATIVE) [2] L. Blunk, J. Vollbrecht, Bernard Aboba, " Extensible Authentication Protocol (EAP) ", RFC 2284bis, February 2002. [3] P. Urien, M. Loutrel,K. Lu, "Introducing Smart Cards for Wireless LAN Security", 10th International Conference on Telecommunication Systems, Monterey, California, October 3-6 2002. [4] P. Urien, M. Loutrel, "The EAP Smart Card, a tamper resistant device dedicated to 802.11 wireless networks", ASWN 2003, July 2003. [5] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3) ", RFC 2251, December 1997. [6] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3) : Attribute Syntax Definitions", RFC 2252, December 1997. [7] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3) : UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997. [8] B. Aboba, D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [9] H. Haverinen, J. Salowey, "EAP SIM Authentication" http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim- 10.txt, work-in-progress, February 2003. [10] W. Simpson, "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [11] N. Haller, C. Metz, P. Nesser, M. Straw, "One-Time Password System", RFC 2289, February 1998. [12] ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002, "ASN.1 encoding rules - Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) ", 2002. [13] FIPS PUB 46-3, Data Encryption Standard (DES), October 1999, http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf. [14] FIPS PUB 81, DES modes of operation, December 1980, http://www.itl.nist.gov/fipspub/fip81.htm. 12 Author's Addresses Pascal Urien ENST Urien & All Informational - Expires June 2004 23 EAP-SSC Secured Smart Card Channel December 2003 46 rue Barrault 75013 Paris Phone: NA France Email: Pascal.Urien@enst.fr Mesmin T. Dandjinou ENST 46 rue Barrault 75013 Paris Phone: NA France Email: mesmin.dandjinou@voila.fr Urien & All Informational - Expires June 2004 24