Internet Draft P.Urien Document: draft-urien-eap-ssc-00.txt M. Dandjinou Expires: December 2003 EAP-SSC Secured Smartcard Channel 1 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. 2 Abstract This document describes a means of setting up an EAP secured channel between a smartcard 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 a smartcard 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 smartcard. Urien & All Informational - Expires December 2003 1 EAP-SSC Secured Smartcard Channel June 2003 Table of Contents 1 Status.............................................................1 2 Abstract...........................................................1 4 EAP-SSC Protocol Data Unit.........................................3 4.1 EAP packet format (Informative).................................3 4.2 EAP-SSC packet format...........................................4 4.2.1 Type field...................................................4 4.2.2 Sub-Type field...............................................5 4.2.3 Flags field..................................................6 4.2.4 Message Length field.........................................7 4.2.5 Payload field................................................7 4.2.6 Digest field.................................................8 5 Setting up the Secured Smartcard Channel...........................8 5.1 SessionÆs Key (SK) calculation..................................9 5.1.1 Overview.....................................................9 5.1.2 SessionÆs key exchange - Symmetric case......................9 5.1.3 SessionÆs key calculation - Asymmetric case.................11 5.2 SessionÆs key validation.......................................14 6 Secure Channel Messages exchanges.................................16 7 Segmentation issue................................................16 8 LDAP messages.....................................................17 9 Examples of traces................................................17 9.1 Traces in a symmetrical key exchange context...................17 9.2 Traces in an asymmetrical key exchange context.................19 10 Intellectual Property Right Notice...............................23 11 References.......................................................23 12 Author's Addresses...............................................24 Urien & All Informational - Expires December 2003 2 EAP-SSC Secured Smartcard Channel June 2003 3 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, requires 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 smartcard 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 smartcard and the Authentication Server via the Authenticator. The purpose of this draft is first to present this new protocol EAP-SSC (Extensible Authentication Protocol - Secured Smartcard 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 smartcard are securely embedded in these PDUs. 4 EAP-SSC Protocol Data Unit EAP-SSC is an authentication protocol for smartcards based on EAP. Before showing the format of its PDUs, let us remind the EAP packet format. 4.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. Urien & All Informational - Expires December 2003 3 EAP-SSC Secured Smartcard Channel June 2003 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. 4.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. 4.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]). Urien & All Informational - Expires December 2003 4 EAP-SSC Secured Smartcard Channel June 2003 A new value of Type field is requested to IANA for distinguishing EAP on smartcards 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). 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]. 4.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: Urien & All Informational - Expires December 2003 5 EAP-SSC Secured Smartcard Channel June 2003 * Sub-type = 1 means that the context of encryption corresponds to the symmetrical model, i.e. one supposes that the Smartcard 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 Smartcard 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. 4.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; 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 X509 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 Urien & All Informational - Expires December 2003 6 EAP-SSC Secured Smartcard Channel June 2003 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 X bit (EAP-SSC Sequence of X509 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. 4.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. 4.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 Urien & All Informational - Expires December 2003 7 EAP-SSC Secured Smartcard Channel June 2003 4.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 the Code, Identifier, Length, Type, Sub-Type, Flags, Message Length, Payload fields of the message and the Session key (Sk). Each time the digest is computed, fields that are used in input should be clearly specified. 5 Setting up the Secured Smartcard 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 SHA-1 algorithm | +-------------------+------------------------------------------+ Table 1 : Operators and functions used for some EAP-SSC fields description. Urien & All Informational - Expires December 2003 8 EAP-SSC Secured Smartcard Channel June 2003 For setting up this Secured Smartcard 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. 5.1 SessionÆs Key (SK) calculation 5.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. 5.1.2 SessionÆs key exchange - Symmetric case When the Authentication Server receives the valid EAP- Response/Identity packet from the Authenticator, it generates a random number r1 of 160 bits (20 bytes) length. This r1 number is then packed in clear text 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) . + +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 the packets format supported by the communication between him and the Supplicant; as a Urien & All Informational - Expires December 2003 9 EAP-SSC Secured Smartcard Channel June 2003 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 number r2 of 160 bits length which is then used to compute the value of Z as follows: Z = r2 XOR D(r1 | s), 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 Smartcard. 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). Note 1 : Conditions and means which are employed to share or distribute in safety the secrecy s between the Authentication Server and the Smartcard are outside of the scope of this draft. It is also supposed to have enough space and processing capabilities to compute SK in the smartcard. Then, the value of Z is packed 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) . + +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 Urien & All Informational - Expires December 2003 10 EAP-SSC Secured Smartcard Channel June 2003 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. 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)) ========================== - - - - - - - - - - > 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. 5.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. Urien & All Informational - Expires December 2003 11 EAP-SSC Secured Smartcard Channel June 2003 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 number r1 which length depends only on him. This r1 number and the optional sequence of certificates named C1 belonging to the Authentication Server are coded in ASN.1 [12] format and packed in clear text in an EAPOR-Request/EAP-SSC/Start packet which is sent to the Supplicant. This packet format is illustrated in the figure 8 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 = 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 smartcard 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 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. Urien & All Informational - Expires December 2003 12 EAP-SSC Secured Smartcard Channel June 2003 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 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 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 number r2 which length is variable 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 | value U in 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 number r2 with the public key of the Authentication Server, and the message digest D0 with the private key of the Supplicant. 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 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. Urien & All Informational - Expires December 2003 13 EAP-SSC Secured Smartcard Channel June 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=0x02 |Identifier=0x01| Length = yÆyÆ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP-SSC-Type | Sub-Type=0x02 | Flags = zÆzÆ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . . Optional sequence of certificates . . 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 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. 5.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 channel between the Supplicant and the Authentication Server. There is no difference between the way this phase is proceeded in a Urien & All Informational - Expires December 2003 14 EAP-SSC Secured Smartcard Channel June 2003 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 signed with the sessionÆs key SK calculated by the Authentication Server; in other words, the transmitted message to the Supplicant by the Authentication Server will be ended by a message digest D1 computed as D1 = D(M1 | SK). 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 verifies that this received D1 data corresponds well to the message digest that it computes locally by using its sessionÆs key SK. When this comparison does not succeed, it 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 of M1; M2 may be a null length message. M2 with D2 will be packed in an EAPOL-Response/EAP-SSC packet and conveyed to the Authentication Server via the Authenticator. 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. 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 10 : Exchanges during the sessionÆs key validation. Urien & All Informational - Expires December 2003 15 EAP-SSC Secured Smartcard Channel June 2003 In the figure 10 is shown an example of exchange during the sessionÆs key validation phase. 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 there are equal, then one can affirm that the Supplicant share indeed the same sessionÆs key with him: sessionÆs key SK has been validated between the Supplicant and the Authentication Server. 6 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 signed 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) in secret key encryption context, and only from (r1, r2) otherwise. At least three messages M1, M2 and M3 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; * M3 a particular message for terminating the exchanges on the secured channel. The EAP-SSC packet containing this last message will have in its Flags field the E (End) bit set. As this message is also signed, all rogue packets with E bit set will have no effect on the Supplicant. Between message M2 and message M3, the Authentication Server and the Supplicant can continue to exchange messages, by taking care to sign each Mi message with the required message digest Di. 7 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-SSC 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. Urien & All Informational - Expires December 2003 16 EAP-SSC Secured Smartcard Channel June 2003 8 LDAP messages If it is assumed a smartcard 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. 9 Examples of traces 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). 9.1 Traces in a symmetrical key exchange context //* value of the shared secret s 83D972D101F40973DEC8E32068B1DE581641EA76 //******************** 1st packet of the exchange *************** //*************** 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) //* value of r2 (20 bytes) generated by the Supplicant E72D5787D1C037E1DE3CFE63DCF5DF8DF2523693 //* value of D(r1 | s) A575616DE4EB41230E39B28A94BB86039E27F8C9 Urien & All Informational - Expires December 2003 17 EAP-SSC Secured Smartcard Channel June 2003 //********************** 2nd packet of the exchange ************* //******************* sent by the Supplicant 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 | +------- Identifier field equals to that of the request packet +------- Code Field set for EAP-Response packet 425836EA352B76C2D0054CE9484E598E6C75CE5A ; Z = r2 XOR D(r1 | s) //* value of the computed SessionÆs Key SK AB5AFE7AC13CEE477BEACE3A5178AD9D7BD7D374 //********************** 3rd packet of the exchange ************* //******************* sent by the AS to the Supplicant ********** 01 A6 00 1B FF 01 08 ; header ^ ^ ----- ^ ^ ^ | | ^ | | | | | | | | +----- Flags field with D (Digest) bit set | | | | +---- Sub-Type field set for symmetrical case | | | +----- EAP-SSC-Type | | +------- Packet Length field | +------- Identifier field has been incremented to 166 +------- Code Field set for EAP-Request packet 22F182938CBA24E4E49D2B5E9EA3B53321DE84FD ; D1 = D("hello" | SK) //********************** 4th packet of the exchange ************* //******************** sent by the Supplicant to the AS ********* 02 A6 00 1B FF 01 08 ; header ^ ^ ----- ^ ^ ^ | | ^ | | | | | | | | +----- Flags field with D (Digest) bit set | | | | +---- Sub-Type field set for symmetrical case | | | +----- EAP-SSC-Type | | +------- Packet Length field | +------- Identifier field equals to that of the request packet +------- Code Field set for EAP-Response packet AB10AB506D923CE0BC60221ACF503D6338C1EDA2 ; D2=D("world" | D1 | SK) Urien & All Informational - Expires December 2003 18 EAP-SSC Secured Smartcard Channel June 2003 //********************** 5th packet of the exchange ************* //******************** sent by the AS (EAP-Success/End) ********* 03 A7 00 1B 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 | +------- Identifier field has been incremented to 167 +------- Code Field set for EAP-Success packet E69D06BA33DF2799B436D65A348F33840B332810 ; D3=D("stop" | D2 | SK) 9.2 Traces in an asymmetrical key exchange context //** 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 Supplicant. //* 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 Urien & All Informational - Expires December 2003 19 EAP-SSC Secured Smartcard Channel June 2003 //********************** 1st packet of the exchange ************ //*************** sent by the Authentication Server (AS) ******* 01 A5 00 2D FF 02 20 ; header ^ ^ ---- ^ ^ ^ | | ^ | | | | | | | | +----- 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 //* 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 9E7EFE6B9C60428CC61C8798C8F4FE4835BA0861 //* value of V on 64 bytes (512 bits) equals to the encryption //* of D0 with the private key K2private of the Supplicant 3A95A34B98F5E009FAE2ECE3F836DFEBB73EEC8B89F733C02F74EBB236AB6151 5D003228F355877C94AFDAAADEC5C47F236F09FE1D8E651FAFE757F064292B73 //********************** 2nd packet of the exchange ************ //******************* sent by the Supplicant 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 Urien & All Informational - Expires December 2003 20 EAP-SSC Secured Smartcard Channel June 2003 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 //* value of the SessionÆs Key SK 3B4C5E8CD72D723A6CC971612DFFED0EB1E8B514 //* value of D1=D("hello" | SK) 772EC3BD82C07C9A8F06FE006ED779EA7AAB8B77 //********************** 3rd packet of the exchange ************ //******************* sent by the AS to the Supplicant ********* 01 A6 00 1B 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 27 | +------- Identifier field has been incremented to 166 +------- Code Field set for EAP-Request packet 772EC3BD82C07C9A8F06FE006ED779EA7AAB8B77 //* value of D2=D("world" | D1 | SK) CB2A67FAEB44BBC841E99ECAD6C8B25B2FCB3122 //********************** 4th packet of the exchange ************ //******************** sent by the Supplicant to the AS ******** 02 A6 00 1B 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 27 | +------- Identifier field is the same as for request packet +------- Code Field set for EAP-Response packet CB2A67FAEB44BBC841E99ECAD6C8B25B2FCB3122 Urien & All Informational - Expires December 2003 21 EAP-SSC Secured Smartcard Channel June 2003 //* value of D3=D("stop" | D2 | SK) D5ACB12A9F74B2E09B5CB1788D1EBE8AE6E8027C //********************** 5th packet of the exchange ************ //******************** sent by the AS (EAP-Success/End) ******** 03 A7 00 1B 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 27 | +------- Identifier field has been incremented +------- Code Field set for EAP-Success packet D5ACB12A9F74B2E09B5CB1788D1EBE8AE6E8027C Urien & All Informational - Expires December 2003 22 EAP-SSC Secured Smartcard Channel June 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 Smartcards for Wireless LAN Security", 10th International Conference on Telecommunication Systems, Monterey, California, October 3-6 2002. [4] P. Urien, M. Loutrel, "The EAP Smartcard, 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. Urien & All Informational - Expires December 2003 23 EAP-SSC Secured Smartcard Channel June 2003 12 Author's Addresses Pascal Urien ENST 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 December 2003 24