EAP Working Group H. Kim Internet-Draft INRIA Expires: August 9, 2004 H. Afifi INT M. Hayashi Hitachi February 9, 2004 EAP Bluetooth Application draft-kim-eap-bluetooth-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 August 9, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Bluetooth protocol suite defines a set of security mechanisms between its devices. All the authentication procedure is based on the knowledge of a shared secret called PIN. Bluetooth suggests to use systems such as Diffie-Hellman method or others else to initiate the PIN between two unknown devices. This draft proposes a simple mechanism that help two entities already presented to an AAA infrastructure share the PIN and start secured Bluetooth communications with Bluetooth Security protocols. Kim, et al. Expires August 9, 2004 [Page 1] Internet-Draft EAP Bluetooth Application February 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Requirement language . . . . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3 Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Architecture Models . . . . . . . . . . . . . . . . . . . . . 6 3. EAP Bluetooth Application . . . . . . . . . . . . . . . . . . 8 3.1 EAP-Bluetooth Packet Format . . . . . . . . . . . . . . . . . 8 3.2 EAP-Bluetooth Success/Failure Packet . . . . . . . . . . . . . 12 3.3 EAP-Bluetooth PIN Request . . . . . . . . . . . . . . . . . . 12 3.4 EAP-Bluetooth PIN Response . . . . . . . . . . . . . . . . . . 14 3.5 Successful EAP-Bluetooth session via Successful Authentication . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . 22 Kim, et al. Expires August 9, 2004 [Page 2] Internet-Draft EAP Bluetooth Application February 2004 1. Introduction In Bluetooth security, a pairwise key for a secure channel is derived from the initial exchange procedure with a pre-shared key, PIN being shared at a pair of Bluetooth devices. The initial key exchange using non-encrypted channels is however the weakest part of Bluetooth security [8]. It recommends that the user be in a private area, before exchanging the PIN, which is a place where we are confident of the unknown devices. It makes difficult perform effectively in a public area. An automatic mechanism of the initial PIN exchange needs to be provided to allow for the Bluetooth security establishment between unknown devices, being managed locally or remotely without complicated options for users. To fulfill these requirements, it is necessary to offer a security model of the automation of the initial PIN exchange procedure for Bluetooth security in coordination of RSN 802.11i [7] in Wireless LANs. 1.1 Requirement language In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [KEYWORDS] [3]. 1.2 Terminology EAP-Bluetooth EAP-Bluetooth protocol allows currently existing EAP based authentication and/or key exchange protocols to be used to establish a secure channel in WLANs and solves a query of PIN request from Mobile terminals. PIN Personal Identification Number. The PIN used to derive a variety of keys for different uses can vary between 1 and 16 octets. Therefore, prior to generation of keys, the PIN must be pre-shared between the Bluetooth devices. Unknown Bluetooth devices Unknown Bluetooth devices are the ones that do not know their information and share any element each other before establishing secure links between them. Kim, et al. Expires August 9, 2004 [Page 3] Internet-Draft EAP Bluetooth Application February 2004 Mobile terminal Mobile terminal that is used in this context is equipped with two interfaces of networks: 802.11 and Bluetooth ones. Bluetooth Box Bluetooth Box is a component coordinated with a Bluetooth device and the corresponding application. It is fixed and connected to the corresponding server through a secure channel. AP Access Point AAA Authentication, Authorization and Accounting. AAA WLAN Server AAA WLAN Server is the one that authenticates mobile terminals that get access to 802.11 network connection. AAA WPAN Server AAA WPAN Server is the one that authenticates Bluetooth devices in Wireless Personal Area Networks. AAA Bluetooth Application Client AAA Bluetooth Client delivers a query of PIN request from the Mobile terminal to the corresponding AAA Bluetooth Server through AAA protocols like Diameter or Radius. Upon receiving a generated PIN, it sends the one back to the Mobile terminal. AAA Bluetooth Application Server AAA Bluetooth Server takes charge of generating a PIN upon request from AAA Bluetooth Clients or applications being used for a specific device. 1.3 Applicability There are several scenarios where the EAP Bluetooth application in AAA infrastructure can be applied. At a train station, a passenger who has a handset with WiFi and Bluetooth interfaces attempts to pay for a train ticket. The toll booth equipped with a Bluetooth device Kim, et al. Expires August 9, 2004 [Page 4] Internet-Draft EAP Bluetooth Application February 2004 provides a means of electric payment. On its entering a Bluetooth zone, the Bluetooth device of its handset detects a signal emitted from the booth and the connection between two Bluetooth devices is established. The passenger transfers the fee of the ticket through the Bluetooth link and after receiving the bill, the transaction of electric payment through Bluetooth is done. Another scenario is a MP3 station that provides music services with the broadcast and downloads of MP3 music through a Bluetooth link in a hall. The user may just listen to its favorite music with a relatively small amount of fee or buy the music selected, paying through a Bluetooth link. Above all, in these scenarios, what we expect to be done before payment is that Bluetooth communication MUST be protected. Kim, et al. Expires August 9, 2004 [Page 5] Internet-Draft EAP Bluetooth Application February 2004 2. Architecture Models The following illustrates the EAP Bluetooth application architecture in the coordination with the AAA infrastructure, which aims for the automation of the PIN distribution. +----------------------+ +----------------------+ | AAA Bluetooth Client | | AAA Bluetooth Server | |---------------+ ! | +-!-----------------!--+ | EAP-Bluetooth | ! | | ! AAA WPAN Server ! | +---!-----------+---!--+ +-!-----------------!--+ | !AAA WLAN Server! | | | +---!---------------!--+ | | | | AAA Bluetooth | | | AAA +-----------------------+ | | Protocol | +---!----+ | | AP | | +---!----+ +------------------+ +------------!--+ | | EAP-Bluetooth | | Bluetooth App | | +-!-----+----------+ +---------------+ | | W-ETH | Bluetooth| Bluetooth link | Bluetooth | | | ! | Device | ) ) )| | |( ( (| Device | | +-!-----+----------+ +---------------+ | | +----------+ The mobile terminal has two interface devices to the wireless connections: wireless Ethernet device and Bluetooth device. The EAP-Bluetooth application on the mobile terminal requests authentication for the AAA server to establish a secure channel with the help of RSN 802.11i and afterwards requests the PIN from the AAA Bluetooth server through the AAA Bluetooth Client. The opposite device that communicates with the mobile terminal contains a Bluetooth device and has a Bluetooth Application on the top of that which MAY be an AAA Bluetooth Client. The EAP-Bluetooth Application takes charge of allowing for the use of existing EAP based authentication protocols like EAP-TLS [1] to establish a security association and performing a query of PIN requests. On receipt of a PIN request packet with a pair of BD-ADDR (Bluetooth Device Address)s from the mobile terminal, the AAA Bluetooth Client containing an EAP-Bluetooth application requests the PIN from the AAA Bluetooth server. After it receives the response with the PIN, the AAA Bluetooth Client forwards it to the mobile terminal and completes. Kim, et al. Expires August 9, 2004 [Page 6] Internet-Draft EAP Bluetooth Application February 2004 The AAA Bluetooth server receives a query of the PIN request and generates the PIN associated with the pair of two BD-ADDRs. We assume that security associations between AP and AAA Server, and between AAA Servers be established. The link between the AAA WPAN Server and the Bluetooth Box is assumed to also be secure with the help of a certain exclusive connection or Internet security protocols [4]. Kim, et al. Expires August 9, 2004 [Page 7] Internet-Draft EAP Bluetooth Application February 2004 3. EAP Bluetooth Application The EAP Bluetooth Application is part of the AAA EAP Bluetooth application and allows for a various series of EAP based authentication methods like EAP-MD5, EAP-TLS, etc. The following shows the protocol layering model of the EAP Bluetooth application. +----------------------------------------------------------+ | Carrier Protocol (PPP, EAPoL, AAA, etc.) | +----------------------------------------------------------+ | EAP | +----------------------------------------------------------+ | EAP-Bluetooth | | +------------------------------------------------------+ | | | EAP based Authentication Protocol (EAP-MD5, EAP-TLS) | | | +------------------------------------------------------+ | +----------------------------------------------------------+ EAP Bluetooth Protocol transfers EAP requests and responses to build up a security association in WLANs with the help of RSN 802.11i, encapsulating EAP packets. Afterwards, it starts to perform a query of PIN requests. 3.1 EAP-Bluetooth Packet Format A summary of the EAP-Bluetooth request/response packet format is shown below. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Flags | Ver | MIC (Message +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Integrity Code) - Optional +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 1 - Request 2 - Response Kim, et al. Expires August 9, 2004 [Page 8] Internet-Draft EAP Bluetooth Application February 2004 Identifier The Identifier field is one octet and used to matching responses with requests. Length The Length field is two octets and indicates the length of the EAP Packet including the Code, Identifier, Length, Type, Flags, Version, optionally MIC, and Data fields. Type TBD - Bluetooth Flags 0 1 2 3 4 +-+-+-+-+-+ |E|B|M|R|R| +-+-+-+-+-+ E = EAP Included B = Bluetooth start M = MIC included R = Reserved (must be zero) The 'E' bit (encapsulated EAP) is set to indicate the presence of the EAP packet based on one of system defined authentication methods, such as EAP-MD5, EAP-OTP, EAP-TLS, etc. The 'B' bit (Bluetooth start) is set in the Bluetooth communication. It differentiates the Bluetooth Start message from the embedded EAP method based message used for authentication or the key distribution. The 'M' bit (MIC included) is set to indicate the presence of the MIC message which is used to verify the integrity of the EAP-Bluetooth message. The 'E' and the 'B' bits are set exclusively. That is, if the 'E' bit is set the 'B' bit SHOULD not be set and if the 'B' bit is set the 'E' bit SHOULD not be set. Version 0 1 2 +-+-+-+ |R|1|0| +-+-+-+ R = Reserved (must be zero) Kim, et al. Expires August 9, 2004 [Page 9] Internet-Draft EAP Bluetooth Application February 2004 MIC The MIC (Message Integrity Code) field is 16 octets and used to verify the integrity of the EAP-bluetooth packets for the client and the server sides. In case of the 'M' bit of Flags field enabled, it MUST be present. The Identifier, Length, and Data fields, plus a shared key are used to generate the MIC. The shared key COULD be a Pairwise Master Key able to be obtained after successfully authenticated, or a Pairwise Temporary Key, or other else. Data The format of the Data field is determined by the Code and Flags fields. The Data field of Request/Response packet with the 'E' bit enabled contains another EAP packet based on other authentication methods as follows: 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 | Type-Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code The Code field is one octet and identical of the one defined in EAP [1]. 1 Request 2 Response 3 Success 4 Failure Identifier The Identifier field is one octet. It is used to match Responses with Requests for the application defined EAP method. In case of retransmission of the packet, the Identifier field MUST be the same as the previous one. It is identical of the one defined in EAP. Length The Length field indicates the length of the embedded EAP packet including the Code, Identifier, Length, Type, and Type-Data. It is identical of the one defined in EAP. Kim, et al. Expires August 9, 2004 [Page 10] Internet-Draft EAP Bluetooth Application February 2004 Type It is identical of the one defined in EAP. In case of the Code Success/Failure value, the Type field is not present. 1 Identity 2 Notification 3 Nak (Response Only) 4 MD5-Challenge 5 One Time Password (OTP) 6 Generic Token Card (GTC) 255 Experimental use Type-Data The format of the Data field is determined by the Code and Type fields. It is identical of the one defined in EAP. In case of the Code Success/Failure value, the Type-Data field is not present. The Data field of Request/Response packet with the 'B' bit enabled contains another EAP packet based on other authentication methods as follows: 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 | AVP Length +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code The AVP Code field is one octet. TBD Bluetooth Device Address TBD Random Token TBD PIN Key AVP Length The AVP Length field is two octets and indicates the length of this AVP including the AVP code, AVP Length, and AVP Data. AVP Data The AVP Data field is determined by the AVP Code values. The AVP consists of the AVP Code, Length and Data fields. other AVPs Kim, et al. Expires August 9, 2004 [Page 11] Internet-Draft EAP Bluetooth Application February 2004 CAN be added subsequently. 3.2 EAP-Bluetooth Success/Failure Packet The EAP-Bluetooth Success/Failure packet format is shown below. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 3 Success 4 Failure Identifier The Identifier field is one octet and aids in matching replies to Response. The Identifier field MUST match the Identifier field of the Response packet that it is sent in response to. Length 4 Description The EAP-Bluetooth Success/Failure packet does not have the MIC field, which MAY be vulnerable to the Denial of Service attack. However, 3.3 EAP-Bluetooth PIN Request Description The EAP-Bluetooth PIN request packet is valid in Request messages that the EAP-Bluetooth Peer sends to the EAP-Bluetooth Server. It is used to request the PIN. The EAP-Bluetooth message exchange MAY take place before the PIN request. Code 1 for Request Identifier Kim, et al. Expires August 9, 2004 [Page 12] Internet-Draft EAP Bluetooth Application February 2004 The Identifier field of the PIN Request MUST be different from the Identifier field of the other packet that it is sent previously. Length The Length field contains the length of the EAP-Bluetooth PIN Request Packet including the Code, Identifier, Length, Type, Flags, Version, optionally MIC, and Data fields. Type TBD for Bluetooth Flags 0 1 2 3 4 +-+-+-+-+-+ |0|1|M|0|0| +-+-+-+-+-+ M = If the MIC field is present 1, otherwise 0 Version 0 1 2 +-+-+-+ |0|1|0| +-+-+-+ MIC The MIC field is 16 octets. If the pair of EAP-Bluetooth peers contains a shared key, the MIC value CAN be calculated by applying the Identifier, Length, and Data fields plus the shared key to a hash function. If the MIC field is present, the 'M' bit of Flags field MUST be set. AVP Code TBD for Bluetooth Device Address of the EAP-Bluetooth Peer who requests the PIN. AVP Length 9 AVP Data Kim, et al. Expires August 9, 2004 [Page 13] Internet-Draft EAP Bluetooth Application February 2004 The AVP Data field contains a Bluetooth Device Address and it is 6 octets. AVP Code TBD for Bluetooth Device Address of the opposite that communicates with the EAP-Bluetooth Peer. AVP Length 9 AVP Data Bluetooth Device Address of the opposite of 6 octet length. AVP Code TBD for a Random Token that is produced by a random number generator on the EAP-Bluetooth Peer. AVP Length 19 AVP Data Random Token of 16 octet length. 3.4 EAP-Bluetooth PIN Response Description The EAP-Bluetooth PIN response packet is valid in Response messages that the EAP-Bluetooth Server sends back to the EAP-Bluetooth Peer. It is used to respond with the PIN. Code 2 for Response Identifier The Identifier field of the PIN Response MUST match the Identifier field of the Request packet that it is sent in response to. Length Kim, et al. Expires August 9, 2004 [Page 14] Internet-Draft EAP Bluetooth Application February 2004 The Length field contains the length of the EAP-Bluetooth PIN Request Packet including the Code, Identifier, Length, Type, Flags, Version, optionally MIC, and Data fields. Type TBD for Bluetooth Flags 0 1 2 3 4 +-+-+-+-+-+ |0|1|M|0|0| +-+-+-+-+-+ M = If the MIC field is present 1, otherwise 0 version 0 1 2 +-+-+-+ |0|1|0| +-+-+-+ MIC The MIC field is 16 octets. If the pair of EAP-Bluetooth peers contains a shared key, the MIC value CAN be calculated by applying the Identifier, Length, and Data fields plus the shared key to a hash function. If the MIC field is present, the 'M' bit of Flags field MUST be set. AVP Code TBD for PIN AVP Length The AVP Length field indicates the length of this AVP including the AVP code, AVP length, and AVP Data fields. AVP Data The AVP Data field contains the PIN key and the length varies between 1 and 16 octets. 3.5 Successful EAP-Bluetooth session via Successful Authentication Kim, et al. Expires August 9, 2004 [Page 15] Internet-Draft EAP Bluetooth Application February 2004 The EAP Bluetooth packets with EAP-Type=Bluetooth contain other EAP packets as an EAP payload. It recognizes the end of other EAP methods by verifying the payload of types of code of EAP packet like Success or Failure and from this point, a security association is established if the EAP based authentication method is successfully done. The EAP Bluetooth application afterwards triggers the execution of the AAA Bluetooth application. EAP-Bluetooth Peer Authenticator AAA Server (End User) (AP) (Bluetooth Client) | EAP Response/ | | | Identity | | |----------------------->| AAA/EAP-Bluetooth | | |----------------------->| | EAP Request/ | | | EAP-Type=Bluetooth, | | | EAP-Flags=10M0, | AAA/EAP-Bluetooth/ | | Data=EAP Request/ | EAP-Open | | EAP-Type=open |<-----------------------| |<-----------------------| | | | | | : : | | : : | | : : | | | | EAP Response/ | | | EAP-Type=Bluetooth, | AAA/EAP-Bluetooth/ | | EAP-Flags=10M0, | Auth-Success | | Data=EAP Success |<-----------------------| |<-----------------------| | | | | | Security Association | | | Established | | |<======================>| | | | | | EAP Request/ | | | EAP-Type=Bluetooth, | | | EAP-Flags=01M0, | | | Data=BD-ADDR+ | | | BD-ADDR+RAND | | |----------------------->| AAA/EAP-Bluetooth | | |----------------------->| | | - | | Request & | EAP Request/ | Receive PIN | EAP-Type=Bluetooth, | - | EAP-Flags=01M0, | AAA/EAP-Bluetooth | | Data=PIN-KEY |<-----------------------| Kim, et al. Expires August 9, 2004 [Page 16] Internet-Draft EAP Bluetooth Application February 2004 |<-----------------------| | | | AAA/EAP-Bluetooth/ | | | Success | | EAP Success |<-----------------------| |<-----------------------| Kim, et al. Expires August 9, 2004 [Page 17] Internet-Draft EAP Bluetooth Application February 2004 4. Security Considerations The security models as defined in the Diameter base protocol [5] and RSN 802.11i [7] are applied to this application. Kim, et al. Expires August 9, 2004 [Page 18] Internet-Draft EAP Bluetooth Application February 2004 5. Acknowledgements The authors would like to thank Walid Dabbous and our colleagues at Planete team for their comments and suggestions. Kim, et al. Expires August 9, 2004 [Page 19] Internet-Draft EAP Bluetooth Application February 2004 References [1] Blunk, L., "Extensible Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-07 (work in progress), December 2003. [2] Josefsson, S., Palekar, A., Simon, D. and G. Zorn, "Protected EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap-07 (work in progress), October 2003. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Maughan, D., Schneider, M. and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [6] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter Network Access Server Application", draft-ietf-aaa-diameter-nasreq-13.txt (work in progress), Oct 2003. [7] "Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: Specification for Robust Security"", ISO/IEC 8802-11 IEEE Std 802.11i/D3.1, 2003. [8] "Specification of the Bluetooth system, Core Version 1.1", Feb 2003. Authors' Addresses Hahnsang Kim (editor) INRIA 2004, Route des Lucioles B.P. 93 Sophia Antipolis 06902 FRANCE Phone: +33 4 92 38 75 77 EMail: Hahnsang.Kim@inria.fr Kim, et al. Expires August 9, 2004 [Page 20] Internet-Draft EAP Bluetooth Application February 2004 Hossam Afifi INT 9 rue, Charles Fourier Evry 91011 FRANCE Phone: +33 1 60 76 47 08 EMail: Hossam.Afifi@int-evry.fr Mosato Hayashi Hitachi Doulines Sophia Antipolis 06560 France Phone: +33 4 EMail: masato.hayashi@hitachi-eu.com Kim, et al. Expires August 9, 2004 [Page 21] Internet-Draft EAP Bluetooth Application February 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Kim, et al. Expires August 9, 2004 [Page 22] Internet-Draft EAP Bluetooth Application February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kim, et al. Expires August 9, 2004 [Page 23]