EMU Working Group P. Urien Internet Draft Telecom ParisTech Intended status: Informational C.Kiennert Telecom ParisTech October 15, 2009 Expires: April 15, 2010 EAP BIO draft-urien-kiennert-emu-bio-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Urien & All Informational - Expires April 2010 [Page 1] Abstract EAP-TTLS is an EAP method that provides secured authentication as described in RFC 5281. This method makes generally use of two phases in order to complete authentication. The first one consists in the authentication of the TTLS server to the client, established by a TLS handshake between the client and the TTLS server. The handshake may be either mutual or one-way. The authentication of the client to the server may then be negotiated during phase two of EAP-TTLS, thanks to widely-deployed authentication mechanisms such as CHAP, PAP, MS-CHAP or MS-CHAP-V2. The purpose of EAP-BIO is to define how to use a biometric authentication mechanism during phase two of EAP-TTLS. This authentication mechanism ranges from physiological characteristics such as fingerprint identification, to behavioral characteristics such as voice or signature analysis. Hence, EAP-BIO combines the security features of EAP-TTLS and biometric authentication. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Urien & All Informational - Expires April 2010 [Page 2] Table of Contents Copyright Notice.................................................. 1 Abstract.......................................................... 2 Conventions used in this document................................. 2 1 Overview........................................................ 4 2 Terminology..................................................... 5 3 Functional Architecture......................................... 6 3.1 Carrier Protocols.......................................... 7 3.2 Security Overview.......................................... 7 4 EAP-BIO Overview................................................ 8 4.1 Phase 1: Handshake......................................... 8 4.2 Phase 2: Tunneled Authentication........................... 8 4.3 AVP format................................................. 9 4.4 AVP sequences............................................. 10 5 Signatures and Smart Cards..................................... 11 5.1 Elements to be secured.................................... 11 5.2 PKCS #1 signature......................................... 11 6 Biometric formats.............................................. 12 6.1 Fingerprint format........................................ 11 6.2 Fingerprint card format................................... 12 7 PKCS #7 capsule................................................ 13 8 AVP Examples................................................... 14 8.1 AVP containing biometric data............................. 14 8.2 AVP containing a PKCS #7 capsule.......................... 14 9 Protocol details............................................... 16 10 IANA Considerations........................................... 17 11 Security Considerations....................................... 17 12 Normative References.......................................... 17 13 Non Normative References...................................... 18 14 Authors' Addresses............................................ 18 Urien & All Informational - Expires April 2010 [Page 3] 1 Overview The Extensible Authentication Protocol (EAP) [RFC 3748] defines a standard message exchange that allows a server to authenticate a client using an authentication method agreed upon by both parties. EAP may be extended with additional authentication methods by registering such methods with IANA or by defining vendor specific methods. EAP Tunneled TLS (EAP-TTLS) [RFC 5281] defines an authentication protocol performing mutual authentication between the client and the server. This authentication can be directly negotiated during the TLS handshake if the client uses a certificate, but contrary to EAP- TLS such a configuration is not required from the client. If the client cannot authenticate to the server with a certificate, then the TLS handshake is used as a first phase allowing the client and the server to implicitly generate keying material in order to create a secure tunnel where the following data are to be transferred. The second phase of EAP-TTLS allows the client to securely authenticate to the server using common protocols such as CHAP, PAP, MS-CHAP or MS-CHAP-V2. Nevertheless, any authentication protocol, such as biometric mechanisms, may be defined. Biometric authentication involves the use of physical and/or behavioural characteristics of individuals to identify them and to control access to places or things, such as computerized equipment, or more specifically, applications running on that equipment. Biometrics has some advantages over more conventional authentication techniques (login and password, PIN codes, etc.) since nothing has to be carried or remembered that might be stolen. Among the many biometric technologies in use are fingerprint analysis, hand geometry analysis, retina scanning, iris scanning, signature analysis, facial recognition, keystroke analysis, and voice analysis. Based on original measurement of a biometric characteristic (i.e. enrolment), a person's identity can thereafter be verified automatically when requesting access to a computer application or to any other resource by re-sampling the characteristic and comparing the biometric data with the enrolment. If a sufficiently close match is found, then the identity is verified. However, the time needed for biometric comparisons with samples in database is much longer than the time required for more widely- deployed authentication mechanisms. Thus, the protocol MUST ask a login from the user before processing its biometric characteristic. Such an implementation will significantly reduce the time required for the authentication since the server only needs to compare the biometric characteristic with one sample from the database. Urien & All Informational - Expires April 2010 [Page 4] 2 Terminology AAA Authentication, Authorization and Accounting - functions that are generally required to control access to a network and support billing and auditing. AAA protocol A network protocol used to communicate with AAA servers; examples include RADIUS and Diameter. AAA server A server which performs one or more AAA functions: authenticating a user prior to granting network service, providing authorization (policy) information governing the type of network service the user is to be granted, and accumulating accounting information about actual usage. AAA/H A AAA server in the user's home domain, where authentication and authorization for that user are administered. Access Point A network device providing users with a point of entry into the network, and which may enforce access control and policy based on information returned by a AAA server. Since the access point terminates the server side of the EAP conversation, for the purposes of this document it is therefore equivalent to the "authenticator" as used in the EAP specification [RFC 3748]. Since the access point acts as a client to a AAA server, for the purposes of this document it is therefore also equivalent to the "NAS", as used in AAA specifications such as [RFC 2865]. Access Domain The domain, including access points and other devices, that provides users with an initial point of entry into the network; for example, a wireless hot spot. Client A host or device that connects to a network through an access point; since it terminates the client side of the EAP conversation, for the purposes of this document, it is therefore equivalent to the "peer", as used in the EAP specification [RFC 3748]. Urien & All Informational - Expires April 2010 [Page 5] Domain A network and associated devices that are under the administrative control of an entity such as a service provider or the user's home organization. Minutia A generic term in biometrics that designates specific points in a fingerprint record such as ridge bifurcations or endpoints. TTLS server A AAA server which implements EAP-TTLS. This server may also be capable of performing user authentication, or it may proxy the user authentication to a AAA/H. User The person operating the client device; though the line is often blurred, "user" is intended to refer to the human being who is possessed of an identity (username), password or other authenticating information, and "client" is intended to refer to the device which makes use of this information to negotiate network access. There may also be clients with no human operators; in this case the term "user" is a convenient abstraction. 3 Functional Architecture +-----------+ +----------+ +----------+ +----------+ | | | | | | | | | client |<--->| access |<--->| TTLS AAA |<---->| AAA/H | | | | point | | server | | server | | | | | | | | | +---------+-+ +----------+ +----------+ +----------+ | random | | Cert |pkcs#7 CMS | | +-v----------+ | | | Biometric | | Reader | | | +------------+ <---- secure password authentication tunnel ---> <---- secure data tunnel ----> Urien & All Informational - Expires April 2010 [Page 6] The architecture depicted above only displays the general organization for message transmission, which means that additional security features are not visible. An overview of the security offered by this architecture will be described below. 3.1 Carrier Protocols As explained in RFC 5281, the entities shown above, except the biometric reader and the client, communicate with each other using carrier protocols capable of encapsulating EAP. The client and the access point communicate typically using a link layer carrier protocol such as PPP or EAPOL. The access point, TTLS server and AAA/H server communicate using a AAA carrier protocol such as RADIUS or Diameter. EAP, and therefore EAP-TTLS, must be initiated via the carrier protocol between the client and the access point. In PPP or EAPOL, for example, EAP is initiated when the access point sends an EAP- Request/Identity packet to the client. The keying material used to encrypt and authenticate the data connection between the client and the access point is developed implicitly between the client and TTLS server as a result of EAP- TTLS negotiation. This keying material must be communicated to the access point by the TTLS server using the AAA carrier protocol. 3.2 Security overview The architecture inherits all the security features of EAP-TTLS, and as such allows secure authentication between the client and the TTLS server. However, the biometric elements have to be implemented with proper security in order not to compromise the whole new authentication protocol. Some of the potential attacks related to biometrics may indeed compromise the security of the protocol and may result in unauthorized access: - If the user gives a false sample to the biometric reader (false finger, mask, eye picture), the reader may grant access according to the false credentials it was given. - If the user manages to send previously acquired samples from another user, the protocol may grant access if it has no protection against replay attacks. These are two potential attacks that are not covered by the security offered by EAP-TTLS. The security features addressing these flaws mainly rely on smart cards and digital signatures, and will be discussed in later sections. Urien & All Informational - Expires April 2010 [Page 7] 4 EAP-BIO Overview Since EAP-BIO relies on EAP-TTLS, the authentication process is the same as EAP-TTLS protocol. It consists of two phases, where phase 1 is a TLS handshake that either performs mutual authentication, or authenticates the TTLS server to the client and allows a secure tunnel to be created, in which authentication data and other significant information will be exchanged during phase 2 of the protocol. 4.1 Phase 1: Handshake In phase 1, the TLS handshake protocol is used to authenticate the TTLS server to the client and, optionally, to authenticate the client to the TTLS server. The TTLS server initiates the EAP-TTLS method with an EAP-TTLS/Start packet, which is an EAP-Request with Type = EAP-TTLS and the S (Start) bit set. This indicates to the client that it should begin TLS handshake by sending a ClientHello message. EAP packets continue to be exchanged between client and TTLS server to complete the TLS handshake, as described in [RFC 5216]. Phase 1 is completed when the client and the TTLS server exchange ChangeCipherSpec and Finished messages. At this point, additional information may be securely tunnelled. As part of the TLS handshake protocol, the TTLS server will send its certificate along with a chain of certificates leading to the certificate of a trusted CA. The client will need to be configured with the certificate of the trusted CA in order to perform the authentication. If certificate-based authentication of the client is desired, the client must have been issued a certificate and must have the private key associated with that certificate. 4.2 Phase 2: Tunneled Authentication In phase 2, the TLS Record Layer is used to securely tunnel information between the client and the TTLS server. This information is encapsulated in sequences of attribute-value pairs (AVPs), whose use and format are described in the next paragraph. The server will ask the client to send its credentials for authentication, and before asking for biometric data, the server MUST ask the user's login. The user will then be asked to submit his biometric characteristic to the reader. Urien & All Informational - Expires April 2010 [Page 8] Such a procedure will allow the biometric characteristic to be compared only with the sample of the specified user, instead of testing all the database samples. Since the comparison algorithm may be complex, a significant amount of time may be saved for the authentication. The login and the biometric characteristic are encapsulated in AVPs, and then transmitted to the server through the secured TLS tunnel. In accordance with the EAP-TTLS protocol, other data may be exchanged between the client and the server using AVPs. The TTLS server recovers the AVPs in clear text from the TLS record layer. If the AVP sequence includes authentication information, it forwards this information to the AAA/H server using the AAA carrier protocol. Note that the EAP-TTLS and AAA/H servers may be one and the same, in which case it simply processes the information locally. When the TTLS server has gathered enough information, it issues either an EAP-Success or EAP-Failure. Thus, if the AAA/H rejects the client based on forwarded authentication information, the TTLS server MUST issue an EAP-Failure. If the AAA/H accepts the client, the TTLS server MUST issue an EAP-Success. The TTLS server distributes data connection keying information and other authorization information to the access point in the same AAA carrier protocol message that carries the EAP-Success. 4.3 AVP format The format of an AVP is shown below. All items are in network, or big-endian, order; that is, they have most significant octet first. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M r r r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data... +-+-+-+-+-+-+-+-+ AVP Code The AVP Code is four octets and, combined with the Vendor-ID field if present, identifies the attribute uniquely. The first 256 AVP numbers represent attributes defined in RADIUS. AVP numbers 256 and Urien & All Informational - Expires April 2010 [Page 9] above are defined in Diameter. The codes used in EAP-BIO are yet to be defined. AVP Flags The AVP Flags field is one octet, and provides the receiver with information necessary to interpret the AVP. The 'V' (Vendor-Specific) bit indicates whether the optional Vendor-ID field is present. When set to 1, the Vendor-ID field is present and the AVP Code is interpreted according to the namespace defined by the vendor indicated in the Vendor-ID field. The 'M' (Mandatory) bit indicates whether support of the AVP is required. If this bit is set to 0, this indicates that the AVP may be safely ignored if the receiving party does not understand or support it. If set to 1, this indicates that the receiving party must fail the negotiation if it does not understand the AVP; for a TTLS server, this would imply returning EAP-Failure, for a client, this would imply abandoning the negotiation. The 'r' (reserved) bits are unused and must be set to 0. AVP Length The AVP Length field is three octets, and indicates the length of this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID (if present) and Data. Vendor-ID The Vendor-ID field is present if the 'V' bit is set in the AVP Flags field. It is four octets, and contains the vendor's IANA- assigned "SMI Network Management Private Enterprise Codes" [9] value. Vendors defining their own AVPs must maintain a consistent namespace for use of those AVPs within RADIUS, Diameter and EAP- TTLS. A Vendor-ID value of zero is equivalent to absence of the Vendor-ID field altogether. 4.4 AVP Sequences Data encapsulated within the TLS Record Layer must consist entirely of a sequence of zero or more AVPs. Each AVP must begin on a 4-octet boundary relative to the first AVP in the sequence. If an AVP is not a multiple of 4 octets, it must be padded with 0s to the next 4- octet boundary. Note that the AVP Length does not include the padding. Urien & All Informational - Expires April 2010 [Page 10] 5 Signatures and Smart Cards Though EAP-TTLS offers high security for authentication, the biometric equipments might be flawed and compromise the whole EAP- BIO protocol. The potential security flaws described in section 3.2 MUST be addressed with smart cards and cryptographic solutions such as digital signatures. The number of signatures used in the protocol will depend on the level of security required. 5.1 Elements to be secured The most important element to be secured should be the biometric reader. In order to prevent material flaws, the reader MUST be certified as secure. If it is not, a signature from the reader would have no meaning. The secure biometric reader should then be affected a smart card in order to store the private key required for the signature. Thus, the biometric characteristic SHOULD be signed by the reader, along with a trusted timestamp in order to prevent replay attacks. The client, whose the biometric characteristic is transmitted to, SHOULD also sign the characteristic before sending it to the TTLS server through the TLS record layer. The third element which may require specific security is the user. Depending on the use case of the EAP-BIO protocol, the authentication may require a smart card from the user, containing his personal public-key certificate. Such a security level may be required in places such as airports. Hence, the biometric authentication requires two or three signatures, depending of the security requested. 5.2 PKCS #1 Signature The signature of the biometric characteristic, along with a trusted timestamp in the case of the biometric reader, is computed according to the PKCS #1 specifications [RFC 3447]. It is here encapsulated in the data field of EAP-TTLS phase 2 AVPs (fourth octet and following). The signature is generated from two steps. The first one consists in encoding the message using EMSA-PSS, described in section 9.1.1 of RFC 3447. Since this is a probabilistic function, the signer has to choose not only a hash function, but also a mask generation function and a salt. The second one consists in the output of the RSA signature. This signature is calculated out of three steps: a. Converting the hashed message to an integer message representative. Urien & All Informational - Expires April 2010 [Page 11] b. Applying a RSA signature primitive (described in section 5.2.1 of RFC 3447) to the private key and the message representative to produce an integer signature representative. c. Converting the signature representative to a signature of k octets, where k is the length in octets of the RSA modulus n. 6 Biometric Formats Many biometric formats, protocols and definitions have been standardized by international organizations such as ISO (International Organization for Standardization), IEC (International Electrotechnical Commission) or JTC1 (Joint Technical Committee One). EAP-BIO shall use the CBEFF (Common Biometric Exchange Formats Framework) data structure, a standard regarding biometrics which describes the necessary data to be inserted in the headers so that different systems may exchange biometric data within only one file. The CBEFF data structure is composed of three parts: the Standard Biometric Header, the Biometric Data Block, and the Signature Block. This data structure is used as a reference in the standards defined for the different biometric characteristics. 6.1 Fingerprint format The requirements for fingerprint analysis are described in the [ISO/IEC 19794] standard. It specifies the content, format and measure units from a fingerprint picture to be used in identification or authentication of a user. The basic entities for fingerprint analysis are ridges and valleys of the finger pattern, and more particularly specific points such as ridge bifurcations (where a ridge is divided in two) and ridge endpoints (where a ridge suddenly stops). The layout of these points is specific to each individual, and as such represents significant information for identification or authentication. The format of a Finger Minutiae Record is described in the ISO/IEC 19794-2 standard, and can be represented as follows: +------------------+------------------------+-------------------+ | Record Header | Single Finger Record | Extended Data | | (24 bytes) | Format | (variable length) | | | (variable length) | | +------------------+------------------------+-------------------+ The header contains information about the characteristics and options of the recording process (equipment, image size, resolution, number of views). Urien & All Informational - Expires April 2010 [Page 12] The Single Finger Record Format block is divided in two parts: the Finger Header block (4 bytes) and the Finger Minutiae Data blocks (6 bytes per block). The Finger Header contains information about the finger position, its quality, as well as the number of minutiae, i.e. bifurcations or endpoints recorded on the fingerprint. The Finger Minutiae Data blocks contain technical data about each minutia recorded (position, angle, quality). One block is added for each minutia. The Extended Data fields may contain any relevant information about the finger minutiae or about the record that could be of use to the equipment retrieving the fingerprint data. The length of these fields (there may be several of them) should be as small as possible. 6.2 Fingerprint Card format The ISO/IEC 19794 standard also defines two possible formats for cards: the Normal Size Finger Minutiae Format, in which the minutiae data are encoded on five octets for each minutia (containing the type, coordinates and angle), and the Compact Size Finger Minutiae Format, in which these data are encoded with lower resolution on three octets. 7 PKCS #7 capsule The biometric characteristic will be signed by two or three signers before being sent to the TTLS server through AVPs. The format described in [RFC 2315] defines two main types for the signature: SignerInfo and SignedData. For each signer, the encrypted message digest and other signer- specific information are collected into a SignerInfo value. Certificates and certificate-revocation lists for each signer, and those not corresponding to any signer, are collected in this step. The defined format is the following: SignerInfo ::= SEQUENCE { version Version, issuerAndSerialNumber IssuerAndSerialNumber, digestAlgorithm DigestAlgorithmIdentifier, authenticatedAttributes [0] IMPLICIT Attributes OPTIONAL, digestEncryptionAlgorithm DigestEncryptionAlgorithmIdentifier, encryptedDigest EncryptedDigest, unauthenticatedAttributes [1] IMPLICIT Attributes OPTIONAL } EncryptedDigest ::= OCTET STRING The timestamp required for the biometric reader signature may be inserted in the authenticatedAttributes field. Urien & All Informational - Expires April 2010 [Page 13] The message-digest algorithms and the SignerInfo values for all the signers are collected together with the content into a PKCS#7 SignedData structure (Object Identifier 1.2.840.113549.1.7.2), the format of which is defined as follows: SignedData ::= SEQUENCE { version Version, digestAlgorithms DigestAlgorithmIdentifiers, contentInfo ContentInfo, certificates [0] IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL, crls[1] IMPLICIT CertificateRevocationLists OPTIONAL, signerInfos SignerInfos } DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier SignerInfos ::= SET OF SignerInfo ContentInfo ::= SEQUENCE { contentType ContentType, content [0] EXPLICIT ANY DEFINED BY contentType OPTIONAL } ContentType ::= OBJECT IDENTIFIER 8 AVP examples The EAP-BIO protocol makes use of AVPs in the second phase of the EAP-TTLS protocol. These AVPs contain information as described in the preceding sections, and can be represented as follows: 8.1 AVP containing biometric data This example displays an AVP containing CBEFF fingerprint data comprised of two minutiae block of the same finger: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M r r r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record Header | Urien & All Informational - Expires April 2010 [Page 14] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Record Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Finger Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Finger Minutiae | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Block 1 | Finger Minutiae | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Block 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Data... +-+-+-+-+-+-+-+-+-+- 8.2 AVP containing a PKCS #7 capsule 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M r r r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + + | | + + | PKCS#7 Signed Data | + Structure + | | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Urien & All Informational - Expires April 2010 [Page 15] 9 Protocol details client access point TTLS server AAA/H ------ ------------ ----------- --- EAP-Request/Identity <-------------------- EAP-Response/Identity --------------------> RADIUS Access-Request: EAP-Response passthrough --------------------> RADIUS Access-Challenge: EAP-Request/TTLS-Start <-------------------- EAP-Request passthrough <-------------------- EAP-Response/TTLS: ClientHello --------------------> RADIUS Access-Request: EAP-Response passthrough --------------------> RADIUS Access-Challenge: EAP-Request/TTLS: ServerHello Certificate ServerKeyExchange ServerHelloDone <-------------------- EAP-Request passthrough <-------------------- EAP-Response/TTLS: ClientKeyExchange ChangeCipherSpec Finished --------------------> RADIUS Access-Request: EAP-Response passthrough --------------------> Urien & All Informational - Expires April 2010 [Page 16] RADIUS Access-Challenge: EAP-Request/TTLS: ChangeCipherSpec Finished <-------------------- EAP-Request passthrough <-------------------- EAP-Response/TTLS: Pkcs#7 CMS --------------------> RADIUS Access-Request: EAP-Response passthrough --------------------> RADIUS Access-Request: pkcs#7 CMS --------------------> RADIUS Access-Accept <-------------------- RADIUS Access-Accept: EAP-Success <-------------------- EAP-Success <-------------------- 10 IANA Considerations 11 Security Considerations 12 Normative References [RFC 5281] Paul Funk, Simon Blake-Wilson, EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0), August 2008 [RFC 5216] D. Simon, B. Aboba, R. Hurst, "The EAP-TLS Authentication Protocol", March 2008. [RFC 3748] B. Aboba, L. Blunk, J. Vollbrecht, J. C. Sun, H. Levkowetz, "Extensible Authentication Protocol (EAP)" RFC 3748, June 2004 [RFC 3447] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", February 2003 Urien & All Informational - Expires April 2010 [Page 17] [RFC 2315] B. Kaliski, "PKCS #7: Cryptographic Message Syntax, Version 1.5", March 1998. [RFC 2865] C. Rigney, S. Willens, A. Rubens, W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", June 2000. [ISO/IEC 19794] BS ISO/IEC 19794 series. "Information technology. Biometric data interchange formats". 13 Non Normative References 14 Authors' Addresses Pascal Urien Telecom ParisTech 37/39 rue Dareau 75014 Paris Phone: NA France Email: Pascal.Urien@enst.fr Christophe Kiennert Telecom ParisTech 37/39 rue Dareau 75014 Paris Phone: NA France Email: Christophe.Kiennert@enst.fr Full Copyright Statement Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Urien & All Informational - Expires April 2010 [Page 18]