One document matched: draft-kim-eap-bluetooth-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 13:18:16 |