idnits 2.17.1 draft-urien-tls-llcp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'NPP' is mentioned on line 172, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group P. Urien 3 Internet Draft Telecom ParisTech 4 Intended status: Experimental 6 July 18 2015 7 Expires: January 2016 9 LLCPS 10 draft-urien-tls-llcp-06.txt 12 Abstract 14 This document describes the support of the TLS protocol over the NFC 15 (Near Field Communication) LLCP (Logical Link Control Protocol) 16 layer, which is referred as LLCPS. The NFC peer to peer (P2P) 17 protocol may be used by any application that needs communication 18 between two devices at very small distances (a few centimeters). 19 LLCPS enforces a strong security in NFC P2P exchanges, and may be 20 deployed for many services, in the Internet of Things (IoT) 21 ecosystem, such as payments, access control or ticketing operations. 22 Applications secured by LLCPS are identified by the service name 23 "urn:nfc:sn:tls:service". 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six 42 months and may be updated, replaced, or obsoleted by other documents 43 at any time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 2016. 48 . 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with 60 respect to this document. Code Components extracted from this 61 document must include Simplified BSD License text as described in 62 Section 4.e of the Trust Legal Provisions and are provided without 63 warranty as described in the Simplified BSD License. 65 Table of Contents 67 Abstract........................................................... 1 68 Requirements Language.............................................. 1 69 Status of this Memo................................................ 1 70 Copyright Notice................................................... 2 71 1 Overview......................................................... 5 72 1.1 About the NFC protocol...................................... 5 73 1.2 The LLCP layer.............................................. 7 74 1.3 LLCPS basic guidelines...................................... 9 75 2 TLS support over LLCP, Connection-oriented Transport............ 10 76 2.1 Peer To Peer Link Establishment............................ 10 77 2.3 Connection Process, the Initiator is Server, the Target is 78 Client......................................................... 13 79 2.3.1 Initiator side ...................................... 13 80 2.3.2 Target side ......................................... 14 81 2.3.3 Connection choreography ............................. 14 82 2.4 Connection Process, the Initiator is Client, the Target is 83 Server......................................................... 14 84 2.4.1 Initiator side ...................................... 14 85 2.4.2 Target side ......................................... 15 86 2.4.3 Connection choreography ............................. 15 87 2.5 Disconnection Process...................................... 15 88 2.5.1 Disconnection initiated by the Initiator ............ 15 89 2.5.2 Disconnection initiated by the Target ............... 15 90 2.5.3 Disconnection choreography .......................... 16 91 2.6 Sending Process............................................ 16 92 2.7 Receiving Process.......................................... 18 93 3 TLS support over LLCP, Connectionless Transport................. 21 94 3.1 Peer To Peer Link Establishment............................ 23 95 3.2 Inactivity Process......................................... 24 96 3.3 Connection Process, the Initiator is Server, the Target is 97 Client......................................................... 24 98 3.3.1 Initiator side ...................................... 24 99 3.3.2 Target side ......................................... 25 100 3.3.3 Connection choreography ............................. 25 101 3.4 Connection Process, the Initiator is Client, the Target is 102 Server......................................................... 25 103 3.4.1 Initiator side ...................................... 25 104 3.4.2 Target side ......................................... 25 105 3.4.3 Connection choreography ............................. 26 106 3.5 Disconnection Process...................................... 26 107 3.5.1 Disconnection initiated by the Initiator ............ 26 108 3.5.2 Disconnection initiated by the Target ............... 26 109 3.5.3 Disconnection choreography .......................... 27 110 3.6 Sending Process............................................ 27 111 3.7 Receiving Process.......................................... 29 112 4 Example of LLCPS session, connected mode........................ 32 113 4.1 Protocol Activation and Parameters Selection............... 32 114 4.1.1 Initiator ATR-REQ ................................... 32 115 4.1.2 Target ATR-RESP ..................................... 32 116 4.2 LLCP connection............................................ 32 117 4.3 Target: sending Client Hello............................... 33 118 4.4 Inactivity Process......................................... 33 119 4.5 Server: sending Server Hello............................... 33 120 4.6 LLCP Inactivity Process.................................... 34 121 4.7 Client: sending Client Finished............................ 34 122 4.8 Exchanging Data............................................ 35 123 4.8.1 Sending data from client to server .................. 35 124 4.8.2 Sending data from server to client .................. 35 125 4.9 Closing TLS session, initiated by the Initiator............ 36 126 5 Example of LLCPS session, Connectionless mode................... 36 127 5.1 Protocol Activation and Parameters Selection............... 36 128 5.1.1 Initiator ATR-REQ ................................... 36 129 5.1.2 Target ATR-RESP ..................................... 36 130 5.2 LLCP connection............................................ 37 131 5.3 Client Hello............................................... 37 132 5.4 Server Hello............................................... 37 133 5.5 Client Finished............................................ 38 134 5.6 Exchanging Data............................................ 38 135 5.6.1 Sending data from client to server .................. 38 136 5.6.2 Sending data from server to client .................. 39 137 5.7 End of Session............................................. 39 138 6 Security Considerations......................................... 40 139 7 IANA Considerations............................................. 40 140 8 References...................................................... 40 141 8.1 Normative References....................................... 40 142 8.2 Informative References..................................... 41 143 9 Authors' Addresses.............................................. 41 144 1 Overview 146 1.1 About the NFC protocol 148 The Near Field Communication protocol (NFC) is based on standards 149 such as [ECMA340] or [ISO/IEC 18092]. It uses the 13,56 MHz 150 frequency, with data rates ranging from 106 To 848 kbps. The working 151 distance between two nodes is about a few centimeters, with 152 electromagnetic fields ranging between 1 and 10 A/M. 154 There are two classes of working operations: 156 - Reader/Writer and Card Emulation. A device named "Reader" feeds 157 another device called "Card", thanks to a 13,56 MHz electromagnetic 158 field coupling. This mode is typically used with [ISO7816] 159 contactless smartcards or with NFC RFIDs. 161 - Peer To Peer (P2P). Two devices, the "Initiator" and the "Target" 162 establish a NFC communication link. In the "Active" mode these two 163 nodes are managing their own energy resources. In the "Passive" mode 164 the Initiator powers the Target via a 13,56 MHz electromagnetic 165 field coupling. 167 This draft focuses on P2P security, which is required by many 168 applications, targeting access control, transport, or other Internet 169 of Things (IoT) items. Although the NFC protocol enables data 170 exchange at small physical distances, it doesn't support 171 standardized security features providing privacy or integrity. Thus, 172 protocols such as [SNEP] or [NPP], whose goal is to push NDEF [NDEF] 173 contents, are not today secured. In this draft we define a profile 174 for TLS support in P2P operations. 176 A P2P session (see figure 1) occurs in four logical phases: 178 1) Initialization and Anti-collision. The Initiator periodically 179 sends a request packet (and therefore generates a RF field), which 180 is acknowledged by a Target response packet. Because several Targets 181 may be located near the Initiator, an anti-collision mechanism is 182 managed by the Initiator in order to establish a session with a 183 single Target. 184 2) Protocol Activation and Parameters Selection. The Initiator 185 starts a logical session with a detected Target by sending a ATR-REQ 186 (Attribute-Request) message, which is confirmed by a Target ATR-RESP 187 (Attribute-Response) message. These messages fix the device IDs 188 (DIDi, Device ID Initiator and DIDt, Device ID Target) used in 189 further packet exchanges. Optional information fields (Gi for the 190 Initiator, and Gt for the Target) identify the protocol to be used 191 over the MAC level; in this document it is assumed that the LLCP 192 [LLCP] (Logical Link Control Protocol) protocol is selected by the 193 Gi and Gt bytes. Optionally some parameters are negotiated by 194 additional packets. 196 3) Data Exchange. Frames are exchanged via the DEP (Data Exchange 197 Protocol) protocol. DEP works with DEP-REQ (DEP-Request) transmitted 198 by the Initiator and DEP-RESP (DEP-Response) delivered by the 199 Target. DEP provides error detection and recovery. It uses small 200 data unit size (from 64 to 256 bytes); however it supports a 201 chaining mode for larger sizes. DEP frames typically transport LLCP 202 packets, and provide an error free service 203 4) De-Activation. The Initiator may deactivate the Target by sending 204 a RLS-REQ (Release Request) message acknowledged by a RLS-RESP 205 (Release Response). 207 Usually, and for practical reasons, P2P sessions are established 208 between a unique Target and an Initiator, for example a mobile phone 209 and another NFC device. They are automatically started when the 210 distance between the two NFC modes is sufficiently small. The MAC 211 link may be broken at any time, as soon as the distance disables 212 radio operations. 214 Initiator Target 215 | | 216 |<------ (1) Initialization and Anti-Collision ------->| 217 | | 218 |<- (2) Protocol Activation and Parameters Selection ->| 219 | ------------------- ATR-REQ -----------------------> | 220 | <------------------ ATR-RESP ----------------------- | 221 | | 222 |<---------------- (3) Data Exchange ----------------->| 223 | LLCP packets over DEP frames | 224 | TLS over LLCP | 225 | | 226 |<----------------(4) De-Activation ------------------>| 227 | | 229 Figure 1. A NFC P2P Session 231 Due to the dissymmetry of the DEP protocol (see figure 2), in which 232 the Initiator sends requests and Target returns responses, the NFC- 233 P2P MAC services are dissymmetric on the Initiator and Target sides. 235 - The Initiator delivers Data.Request-i and gets Data.Indication-i. 236 - The Target gets Data.Indication-t and delivers Data.Request-t 238 MAC services implemented by NFC controllers usually support such 239 dissymmetric primitives for Initiator and Target procedures (MAC 240 Data.request-i/t and Data.Indication-i/t). 242 The timeout value (between DEP-REQ and DEP-RESP messages) is deduced 243 from the RWT attribute (Response Waiting Time) returned by the 244 Target in the ATR-RESP message. RWT ranges between 0,6 ms and 9,9 245 ms. It may be extended to the RWT-INT by a factor RTOX (RWT-INT = 246 RTOX x RWT) between 1 and 60, so the maximum value is about 6s. 248 Initiator Target 249 | | | | 250 | | | | 251 | Data.Request-i --- DEP-REQ --> Data.Indication-t | 252 | | | 253 | RWT-INT ms | 254 | | | 255 Data.Indication-i <---- DEP-RESP --------- Data.Request-t 257 Figure 2. NFC-P2P MAC layer service, based on DEP frames 259 1.2 The LLCP layer 261 The LLCP [LLCP] protocol works like a light LLC [IEEE 802.2] layer. 262 It provides two classes of services, connectionless transport and 263 connection-oriented transport. 265 This draft focuses both on connection-oriented transport, in which 266 TLS services are identified by a Service Name (SN), and on non- 267 connected mode, in which a fix (well-known) Service Access Point 268 (SAP) is used. 270 A LLCP packet (see figure 3) comprises three mandatory fields, DSAP 271 (Destination Service Access Point, 6 bits), SSAP (Source Service 272 Access Point, 6 bits), and PTYPE (Protocol data unit type field, 4 273 bits). 275 An optional sequence field (8 bits) contains two 4 bits number N(S) 276 and N(R) respectively giving the number of the information SDU to be 277 sent and the number of the next information PDU to be received. 279 An optional Information field transports the LLCP payload. 281 <--------------LLCP Header--------------><-LLCP Payload -> 282 | DSAP | PTYPE | SSAP | Sequence | INFORMATION | 283 | 6 bits | 4 bits | 6 bits | 0 or 8 bits | M x 8 bits | 285 Figure 3. Structure of an LLCP packet 287 There are sixteen types of LLCP packets, identified by PTYPE values 288 ranging between 0 and 15. In this draft we use only nine of these 289 PDUs. 291 1) Symmetry (SYMM, PTYPE=0, DSAP=SSAP=0, No Sequence, No 292 Information). This PDU is produced as soon as there is no 293 information to provide. This mechanism avoids timeout at the MAC 294 (DEP) level. SYMM SHOULD be generated after an inactivity period of 295 about LTO/2, where LTO is the link timeout. 297 2) Connect (CONNECT, PTYPE=4, No sequence, Information). This PDU 298 MUST include a SN (service name parameter) that identified the TLS 299 service ("urn:nfc:sn:tls:service"). It uses a DSAP value set to 1 300 (the SAP of the Service Discovery Protocol, SDP) and a SSAP value 301 ranging between 16 and 31. It indicates the connection the well- 302 known service (WKS) SDP (SAP=1), which SHOULD deliver an ephemeral 303 SAP (SAP-client) ranging between 16 and 31. 305 3) Connection Complete (CC, PTYPE=6, No sequence, Optional 306 Information). This PDU notifies the successful connection to the 307 "urn:nfc:sn:tls:service" service. It allocates the SAP (DSAP=SAP- 308 client) to be used for this session identified by the tuple (SAP- 309 server, SAP-client) 311 4) Disconnection (DISC, PTYPE=5, No sequence, No Information). This 312 PDU indicates the disconnection of the (SAP-server, SAP-client) 313 session. Null SAP values MAY be used to notify the disconnection of 314 the LLCP entity. 316 5) Disconnected Mode (DM, TYPE=7, No sequence, one byte of 317 Information). This PDU confirms the disconnection of the (SAP- 318 server, SAP-client) session; one information byte gives the 319 "Disconnected Mode Reasons". Null SAP values notify the 320 disconnection of the LLCP entity. 322 6) Information (INFORMATION, PTYPE=10, Sequence, information). This 323 PDU transport a SDU; N(S) indicates the SDU number, N(R) indicates 324 the next SDU number to be received. In this draft the Receive 325 Windows Size (RW) MUST be set to one, which is the default LLCP 326 value. 328 7) Receive Ready (RR, PTYPE=11, sequence N(R) only, no Information). 329 This PDU is used for the acknowledgment of previously received 330 information PDU. It indicates the next sequence number (N(R)) to be 331 received. 333 8) Receive Not Ready (RNR, PTYPE=12, sequence N(R) only, no 334 Information).This PDU indicates a temporary inability to process 335 subsequent information PDUs. 337 9) Unnumbered Information (UI, PTYPE=3, no Sequence, Optional 338 Information). This PDU is used to transfer service data units to the 339 peer LLC without prior establishment of a data link connection. 341 According to [LLCP] some LLCP functional parameters are updated by 342 LLCP-Parameter attributes exchanged in LLCP packets or in ATR-REQ 343 and ATR-RESP messages. Parameters are encoding according to TLV 344 format, in which Type size is one byte, Length size is one byte and 345 Value is a set of L bytes. In this document we use 6 parameters. 347 1) Version Number (VERSION, T=01h, L=01h, V=10h). In this document 348 this option MUST be included in the general bytes of ATR-REQ and 349 ATR-RESP. 351 2) Maximum Information Unit Extension (MIUX, T=02h, L=02h). This 352 parameter extends the maximum size of the LLCP PDU (MIU), whose 353 default value is 128 bytes, according to the relation: MIU = MIUX + 354 128. The MIUX parameter MAY be inserted in general bytes of ATR-REQ 355 and ATR-RESP, and in LLCP PDUs CONNECT and CC. 357 3) Well-Known Service List (WKS, T=03h, L=02h). This parameter 358 associates a bit to the instance of a well-known LLCP parameter. A 359 typical value is 00001h, indicating the availability of the DSP 360 service. WKS MAY be inserted in general bytes of ATR-REQ and ATR- 361 RESP. 363 4) Link Timeout (LTO, T=04h, L=01h). This parameter indicates the 364 timeout value for the LLCP layer, in multiples of 10ms. LTO MAY be 365 inserted in general bytes of ATR-REQ and ATR-RESP. 367 5) Receive Windows Frame (RW, T=05h, L=01h). This parameter 368 indicates the size of the receive windows, its value ranges between 369 0 and 15. The default value is one, and MUST be set to one according 370 to this document. It MAY be inserted in LLCP PDUs CONNECT or CC. 372 6) Service Name (SN, T=06h). This parameter indicates the name of a 373 service. It MUST be inserted in the CONNECT PDU. In this document 374 its value is set to "urn:nfc:sn:tls:service", where "service" is the 375 application name securely transported by TLS. 377 1.3 LLCPS basic guidelines 379 The TLS protocol is a series of record messages, which MAY be 380 encrypted or integrity-protected. Each record message includes a 381 five bytes prefix that comprises three attributes: 382 - The type (one byte) of the message, 383 - The version (two bytes), 384 - The message length (two bytes). 386 The client and the server exchange RECORD messages whose meaning is 387 deduced from the TLS protocol rules, according to a half-duplex 388 paradigm. Therefore as soon as the beginning of the TLS session is 389 detected, the two TLS entities alternatively send and receive a set 390 of record messages, whose synchronization is handled by the 391 knowledge of TLS protocol. 393 The EAP-TLS protocol [RFC 5216] demonstrates how TLS record messages 394 may be gathered in blocks exchanged according to a half-duplex 395 mechanism. 397 LLCPS specifies the TLS session establishment and release, and the 398 transport of TLS packets in a NFC P2P context. 400 Applications secured by LLCPS are identified by the service name 401 "urn:nfc:sn:tls:service" where "service" is the application name. 403 2 TLS support over LLCP, Connection-oriented Transport 405 In NFC P2P mode the Initiator detects a Target and afterwards starts 406 and manages a data exchange session; it may optionally feeds the 407 Target device. The Initiator has consequently a longer useful life 408 than the Target; it is a legitimate place to host TLS server in a 409 permanent way. 411 However the TLS server MAY be hosted on the Initiator or on the 412 Target side. 414 Each entity manages five exclusive processes 416 - The Connection Process (CP) 417 - The Disconnection Process (DP) 418 - The Sending Process (SP) 419 - The Receiving Process (RP) 420 - The Inactivity Process (IP) 422 The Inactivity Process MAY be started (see figure 4) each time a 423 receiving or sending buffer is empty; in this case it is assumed 424 that the computing time or the delay required before the next 425 input/output operation is greater than the LLCP timeout (LTO). 427 2.1 Peer To Peer Link Establishment 429 As described in section 1, the Initiator periodically probes the 430 presence of a Target. At the end of the "Protocol Activation and 431 Parameters Selection" phase, ATR-REQ and ATR-RESP messages have been 432 exchanged, and LLCP services are available on both Initiator and 433 Target nodes, including in particular the Data-Request-i/t and Data- 434 Indication-i/t primitives. 436 Due to the ephemeral intrinsic nature of an NFC connection, the P2P 437 session may be broken at any time, which implies transmission or 438 reception errors notified by the MAC primitives. 440 As a consequence an LLCP session is assumed to be released at the 441 first MAC error. 443 Once a NFC P2P link is established, TLS server and client software 444 entities are activated. Procedures such as: 446 - SOCKET acceptllcp (char *ServiceName), and 447 - SOCKET connectllcp(char *ServiceName) 448 MAY be used respectively on Initiator and Target sides, in order to 449 get a SOCKET. 451 A SOCKET object supports additional facilities, typically the 452 following procedures: 454 - int sendllcp(SOCKET s, char *buffer, int length) 455 - int recvllcp(SOCKET s, char *buffer, int length) 456 - int closellcp(SOCKET s) 458 which are used for the LLCP session management. 460 Initiator Target 461 | | 462 Connection Process Connection Process 463 | | 464 Send SYMM ---------------> Receive SYMM 465 Receive CONNECT <---------------- Send CONNECT 466 Send CC ----------------> Receive CC 467 Receive SYMM <---------------- Send SYMM 468 | | 469 =========================TLS Session============================ 470 | | 471 Receiving Process Sending Process 472 | | 473 Send SYMM -------------> Receive SYMM 474 Receive INFORMATION <------------ Send INFORMATION 475 Send RR -------------> Receive RR 476 Receive SYMM <------------- Send SYMM 477 | | 478 Inactivity Process Receiving Process 479 | | 480 Send SYMM ------------------> Receive SYMM 481 Receive SYMM <----------------- Send SYMM 482 | | 483 Sending Process | 484 | | 485 Send INFORMATION ---------------> Receive INFORMATION 486 Receive RR <-------------- Send RR 487 | | 488 Receiving Process Inactivity Process 489 | | 490 Send SYMM -------------------> Receive SYMM 491 Receive SYMM <------------------ Send SYMM 492 | | 493 | Receiving Process 494 | | 495 Send SYMM ------------> Receiving SYMM 496 Receive INFORMATION <----------- Send INFORMATION 497 Send RR ------------> Receive RR 498 Receive SYMM <----------- Send SYMM 499 | | 500 ===========================End Of TLS Session===================== 501 | | 502 Inactivity Process Inactivity Process 503 | | 504 Disconnection Process | 505 | | 506 Send DISC -------------------> Receive DISC 507 Receive DM <------------------- Send DM 508 | | 510 Figure 4. Overview of Operations, Connected Mode 511 2.2 Inactivity Process 513 When the LLCP layer detects an inactivity period greater than a 514 given timeout value (see figure 5), it generates a SYMM PDU. 515 Therefore each time a LLCP layer is waiting for a non SYMM PDU, and 516 receives a SYMM PDU, it MUST acknowledge it by sending a SYMM PDU. A 517 maximum number (SYMM-Ct-i/t) of echoed SYMM PDU SHOULD be defined. 519 The Inactivity Process (IP) MAY start between the Receiving Process 520 (RP) and the Sending Process (SP). 522 Upon the reception of an INFORMATION PDU, the packet is stored in 523 the reception buffer, and is acknowledged by a RR PDU. 525 Initiator Target 526 | | 527 +------> LLCP inactivity + <-------------+ 528 | | | | 529 | +----------+-----------+ +------------+-----------+ | 530 | + Inactivity Timeout + + Waiting for a LLCP PDU + | 531 | +----------+-----------+ +------------+-----------+ | 532 | | | | 533 | Send SYMM PDU ----> Reception of a PDU | 534 | | | | | 535 | | |SYMM |Other | 536 | Reception of a PDU <---- |Send SYMM PDU |PDU | 537 | | | | |Excepted| 538 | SYMM| |Other PDU SYMM-Ct-t++ |INFOR- | 539 | SYMM-Ct-i++| |Excepted | |-MATION | 540 +-------------+ +--+INFORMATION +------------|--------+ 541 | | 542 End Of LLCP Inactivity Send a LLCP PDU 544 Figure 5. Inactivity Process 546 2.3 Connection Process, the Initiator is Server, the Target is Client 548 2.3.1 Initiator side 550 The Initiator MUST transmit a SYMM LLCP PDU. 552 The Initiator MUST receive a CONNECT PDU, with DSAP=1, including the 553 SN option, whose value MUST be set to "urn:nfc:sn:tls:service". If 554 the SN value is incorrect the Initiator transmits a DM PDU with a 555 reason code. 557 The Initiator MUST send a CC PDU, with an SSAP ranging between 16 558 and 31. 560 The Initiator SHOULD receive a SYMM PDU. It MAY receive an 561 INFORMATION PDU but this behavior is not recommended, since it 562 complicates the implementation of the acceptllcp (and connectllcp) 563 procedure. 565 2.3.2 Target side 567 The Target MUST wait for the reception of a SYMM PDU 569 The Target MUST send a CONNECT PDU, with DSAP=1 and SSAP ranging 570 between 16 and 31, including the option SN, whose value MUST be set 571 to "urn:nfc:sn:tls:service". 573 The Target MUST receive a CC PDU. 575 The Target SHOULD send a SYMM PDU. It MAY send an INFORMATION PDU 576 but this behavior is not recommended, since it complicates the 577 implementation of the connectllcp (and acceptllcp) procedure. 579 2.3.3 Connection choreography 581 Initiator Target 582 | | 583 socket= acceptllcp() socket=connectllcp() 584 | | 585 Send SYMMM ------------> Receive SYMM 586 | | 587 Receive CONNECT <------------- Send CONNECT, DSAP=1 588 Check SN SN = "urn:nfc:sn:tls:x" 589 | | 590 Send CC --------------> Receive CC 591 Allocate Ephemeral SAP | 592 | | 593 Receive SYMM <-------------- Send SYMM 594 | | 595 Done Done 597 Figure 6. Connection Choreography 599 2.4 Connection Process, the Initiator is Client, the Target is Server 601 2.4.1 Initiator side 603 The Initiator MUST send a CONNECT PDU, with DSAP=1 and SSAP ranging 604 between 16 and 31, including the SN option, whose value MUST be set 605 to "com.ietf.tls. 607 The Initiator MUST receive a CC PDU. 609 2.4.2 Target side 611 The Target MUST receive a CONNECT PDU, with DSAP=1, including the SN 612 option, whose value MUST be set to "urn:nfc:sn:tls:service". If the 613 SN value is incorrect the Initiator transmits a DM PDU with a reason 614 code. 616 The Target MUST send a CC PDU, with an SSAP ranging between 16 and 617 31. 619 2.4.3 Connection choreography 621 Initiator Target 622 | | 623 socket= connectllcp() socket= acceptllcp() 624 | | 625 Send CONNECT, DSAP=1 --------------> Receive CONNECT 626 SN = "urn:nfc:sn:tls:service" Check SN 627 | Allocate Ephemeral SAP 628 | | 629 Receive CC <-------------- Send CC 630 | | 631 | | 632 Done Done 634 Figure 7. Connection Choreography 636 2.5 Disconnection Process 638 Due to the ephemeral nature of P2P NFC session, the disconnection 639 process MAY be unavailable. Nerveless it SHOULD be used for a 640 graceful closing of a TLS session. 642 The Disconnection Process is started by the Initiator or the Target. 644 2.5.1 Disconnection initiated by the Initiator 646 The Initiator MUST send a DISC PDU. 648 The Target receives the DISC PDU. 650 The Target MUST send the DM PDU. 652 The Initiator MUST receive the DM PDU. 654 2.5.2 Disconnection initiated by the Target 656 The Target receives a LLCP PDU. If it receives DISC then it sends 657 DM; else it sends the DISC PDU. 659 The target waits for an LLCP PDU. Upon reception of a LLCP PDU it 660 MUST send the SYMM or the DM PDU. 662 2.5.3 Disconnection choreography 664 Initiator Target 665 | | 666 closellcp(socket) | 667 | | 668 Send DISC --------------> Receive DISC 669 | | 670 Receive DM <-------------- Send DM 671 | | 672 Done 674 Figure 8. Disconnection started by the Initiator 676 Initiator Target 677 | | 678 | closellcp(socket) 679 | | 680 Send SYMM -------------> Receive LLCP PDU 681 | | | 682 | | DISC |Other 683 |<-----------------------+ Send DM |(SYMM) 684 | | Done | 685 |<------------------------------------+Send DISC 686 Receive LLCP PDU | 687 | | | 688 | DM |DISC Receive LLCP PDU 689 | |Send DM | 690 Send DM ---------------------> Receive DM 691 | | 692 | <----------------------------- +Send SYMM 693 | |or DM 694 | Done 695 | | 697 Figure 9. Disconnection started by the Target 699 2.6 Sending Process 701 The data transmission is managed by the sendllcp(SOCKET s, char 702 *buffer, int length) procedure. 704 2.6.1 Initiator side 706 The buffer to be transmitted is segmented in LLCP INFORMATION 707 packets. 709 Each packet MUST be acknowledged by the Target with a RR PDU. 711 If a RNR PDU is received instead of a RR PDU then the initiator 712 sends a SYMM PDU that should be acknowledged either by a SYMM (if 713 the target is still overloaded) or by a RR PDU (if the target is 714 ready again to process INFORMATION PDUs). 716 Initiator Target 717 | | 718 Sendllcp(buffer) recvllcp() 719 | | 720 Send INFORMATION PDU -----------------> Receive INFORMATION PDU 721 NS-i++ | 722 | | 723 Receive RR <--------------------------- Send RR(NR-t) 724 | | 725 Send INFORMATION PDU -----------------> Receive INFORMATION PDU 726 NS-i++ | 727 | | 728 Receive RR <--------------------------- Send RR(NR-t) 729 | | 730 Buffer Empty | 731 | 732 Done 734 Figure 10. Sending Process, Initiator side. 736 2.6.2 Target side 738 The Target switches to the sending process, managed by the 739 sendllcp() procedure. 741 The Target MUST receive a SYMM PDU. 743 The buffer to be sent is segmented in INFORMATION PDUs. 745 Each INFORMATION PDU is sent by the Target to the Initiator and MUST 746 be acknowledged by a RR PDU. 748 If a RNR PDU is received instead of a RR PDU then the target sends a 749 SYMM PDU that should be acknowledged either by a SYMM (if the 750 initiator is still overloaded) or by a RR PDU (if the initiator is 751 ready again to process INFORMATION PDUs). 753 Upon the reception of the last RR PDU a SYMM PDU MUST be sent by the 754 Target to the Initiator. 756 Initiator Target 757 | | 758 recvllcp() sendllcp(buffer) 759 | | 760 Send SYMM --------> Receive SYMM 761 | | 762 Receive INFORMATION PDU <------- Send INFORMATION PDU 763 | NS-t++ 764 | | 765 SEND RR(NR-i) -------> Receive RR 766 | | 767 Receive INFORMATION PDU <------- Send INFORMATION PDU 768 | NS-t++ 769 | | 770 SEND RR(NR-i) -------> Receive RR 771 | | 772 | Buffer Empty 773 | | 774 Receive SYMM <------- Send SYMM 775 | | 776 Done Done 778 Figure 11. Sending Process, Target side. 780 2.7 Receiving Process 782 The Receiving process is handled by the recvllcp(SOCKET s, char 783 *buffer, int length) procedure, which manages a reception buffer. 785 2.7.1 Initiator side 787 A1) If the reception buffer is empty, the Initiator sends a SYMM 788 PDU. This PDU starts the Target receiving process. The expected PDU 789 received from the Target is either an INFORMATION PDU or a SYMM PDU 790 (notifying an ephemeral inactivity state). 792 B1) If the reception buffer stores enough data, then the size 793 requested by the recvllcp() procedure is returned. If the buffer 794 gets empty after this operation, a RR PDU is sent to the Target. The 795 PDU received from the Target is either an INFORMATION PDU or a SYMM 796 PDU. 798 B2) Else, while there is not enough data in the buffer, the 799 following loop is performed 800 - Send RR PDU 801 - Receive INFORMATION PDU 803 B2.1) at this end of this loop the size requested by the recvllcp() 804 procedure is returned. If the buffer gets empty after this 805 operation, a RR PDU is sent to the Target. The PDU received from the 806 Target is either an INFORMATION PDU or a SYMM PDU. 808 Initiator Target 809 | | 810 buffer empty sendllcp() 811 | | 812 recvllcp() ===> Send SYMM --------> Receive SYMM 813 | | 814 Receive INFORMATION PDU <------- Send INFORMATION PDU 815 | NS-t++ 816 enough data <=== | | 817 | | 818 recvllcp() ===> | | 819 enough data <=== | | 820 buffer empty | 821 | | 822 Send RR(NR-i) -------> Receive RR 823 | | 824 Receive INFORMATION PDU <------- Send INFORMATION PDU 825 | NS-t++ 826 | | 827 recvllcp() ===> Send RR(NR-i) -------> Receive RR 828 | | 829 Receive INFORMATION PDU <------- Send INFORMATION PDU 830 | NS-t++ 831 enough data <=== | | 832 | | 833 recvllcp() ===> | | 834 Send RR(NR-i) -------> Receive RR 835 | | 836 Receive INFORMATION PDU <------- Send INFORMATION PDU 837 | NS-t++ 838 | | 839 ===> Send RR(NR-i) -------> Receive RR 840 | | 841 Receive INFORMATION PDU <------- Send INFORMATION PDU 842 | NS-t++ 843 enough data <=== | | 844 buffer empty | 845 | | 846 Send RR(NR-i) -------> Receive RR 847 | | 848 | buffer empty 849 | | 850 Receive SYMM <------- Send SYMM 851 | | 852 Done Done 854 Figure 12. Receiving Process, Initiator side. 856 2.7.2 Target side 858 A1) If the reception buffer stores enough data, then the size 859 requested by the recvllcp() procedure is returned. 861 B1) Else, while there is not enough data in the buffer, the 862 following loop is performed 863 - Receive INFORMATION PDU 864 - Send RR PDU 866 Initiator Target 867 | | 868 Sendllcp(buffer) buffer empty 869 | | 870 | | <=== recvllcp() 871 | | 872 Send INFORMATION PDU ----> Receive INFORMATION PDU 873 NS-i++ | 874 | | 875 Receive RR <------------ Send RR(NR-t) 876 | | 877 | | ===> enough data 878 | | 879 | | <=== recvllcp() 880 | | ===> enough data 881 | | 882 | buffer empty 883 | | 884 | | <=== recvllcp() 885 | | 886 Send INFORMATION PDU --> Receive INFORMATION PDU 887 NS-i++ | 888 | | 889 Receive RR <------------ Send RR(NR-t) 890 | | 891 Send INFORMATION PDU --> Receive INFORMATION PDU 892 NS-i++ | 893 | | 894 Receive RR <------------ Send RR(NR-t) 895 | | 896 buffer empty | ===> enough data 897 | buffer empty 898 Done | 899 Done 901 Figure 13. Receiving Process, Initiator side. 903 3 TLS support over LLCP, Connectionless Transport 905 In NFC P2P mode the Initiator detects a Target and afterwards starts 906 and manages a data exchange session; it may optionally feed the 907 Target device. 909 The Initiator has consequently a longer useful life than the Target; 910 it is a legitimate place to host TLS server in a permanent way. 912 However the TLS server MAY be hosted on the Initiator or on the 913 Target side. 915 Each entity manages five exclusive processes 917 - The Connection Process (CP) 918 - The Disconnection Process (DP) 919 - The Sending Process (SP) 920 - The Receiving Process (RP) 921 - The Inactivity Process (IP) 923 The Inactivity Process MAY be started (see figure 14) each time a 924 receiving or sending buffer is empty; in this case it is assumed 925 that the computing time or the delay required before the next 926 input/output operation is greater than the LLCP timeout (LTO). 928 Initiator Target 929 | | 930 Connection Process Connection Process 931 | | 932 | Sending Process 933 | | 934 Send SYMM ---------------> Receive SYMM 935 Receive UI <---------------- Send UI 936 | | 937 Receiving Process | 938 | | 939 Send SYMM -----------------> Receive SYMM 940 Receive UI <---------------- Send UI 941 | | 942 | Inactivity Process 943 | | 944 Send SYMM ----------------> Receive SYMM 945 Receive SYMM <---------------- Send SYMM 946 | | 947 Inactivity Process Receiving Process 948 | | 949 Send SYMM -----------------> Receive SYMM 950 Receive SYMM <---------------- Send SYMM 951 | | 952 Sending Process | 953 Send UI ------------------> Receive UI 954 Receive SYMM <----------------- Send SYMM 955 | | 956 Receiving Process Inactivity Process 957 | | 958 Send SYMM -----------------> Receive SYMM 959 Receive SYMM <---------------- Send SYMM 960 | | 961 | Sending Process 962 Send SYMM ------------> Receiving SYMM 963 Receive UI <------------- Send UI 964 | | 965 | Inactivity Process 966 Send SYMM -----------------> Receive SYMM 967 Receive SYMM <---------------- Send SYMM 968 | | 969 | | 970 Disconnection Process | 971 | | 972 Send DM --------------> Receive DM 973 Receive SYMM or DM <------------ Send SYMM or DM 974 | | 976 Figure 14. Overview of Process Operations, connectionless mode 977 3.1 Peer To Peer Link Establishment 979 As described in section 1, the Initiator periodically probes the 980 presence of a Target. At the end of the "Protocol Activation and 981 Parameters Selection" phase, ATR-REQ and ATR-RESP messages have been 982 exchanged, and LLCP services are available on both Initiator and 983 Target nodes, including in particular the Data-Request-i/t and Data- 984 Indication-i/t primitives. 986 Due to the ephemeral intrinsic nature of an NFC connection, the P2P 987 session may be broken at any time, which implies transmission or 988 reception errors notified by the MAC primitives. 990 As a consequence an LLCP session is assumed to be released at the 991 first MAC error. 993 Once a NFC P2P link is established, TLS server and client software 994 entities are activated. Procedures such as: 996 - SOCKET acceptllcp(char TLS-SAP), and 997 - SOCKET connectllcp(char TLS-SAP) 999 MAY be used respectively on Initiator and Target sides, in order to 1000 get a SOCKET. This object supports additional facilities, typically 1001 the following procedures: 1003 - int sendllcp(SOCKET s, char *buffer, int length) 1004 - int recvllcp(SOCKET s, char *buffer, int length) 1005 - int closellcp(SOCKET s) 1007 which are used for the LLCP session management. 1009 3.2 Inactivity Process 1011 When the LLCP layer detects an inactivity period greater that a 1012 given timeout value (see figure 15), it generates a SYMM PDU. 1013 Therefore each time a LLCP layer is waiting for a non SYMM PDU, and 1014 receives a SYMM PDU, it MUST acknowledge it by sending a SYMM PDU. A 1015 maximum number (SYMM-Ct-i/t) of echoed SYMM PDU SHOULD be defined. 1017 Upon the reception of an UI PDU, the packet is stored in the 1018 reception buffer. 1020 The Inactivity Process (IP) MAY start between the Receiving Process 1021 (RP) and the Sending Process (SP). 1023 Initiator Target 1024 | | 1025 +------> LLCP inactivity + <-------------+ 1026 | | | | 1027 | +----------+-----------+ +------------+-----------+ | 1028 | + Inactivity Timeout + + Waiting for a LLCP PDU + | 1029 | +----------+-----------+ +------------+-----------+ | 1030 | | | | 1031 | Send SYMM PDU ----> Reception of a PDU | 1032 | | | | | 1033 | | |SYMM or UI |Other | 1034 | Reception of a PDU <---- |Send SYMM PDU |PDU | 1035 | | | | |Excepted| 1036 | SYMM or UI| |Other PDU SYMM-Ct-t++ |UI | 1037 | SYMM-Ct-i++| |Excepted UI | | | 1038 +-------------+ +--+ +------------|--------+ 1039 | | 1040 End Of LLCP Inactivity Send a LLCP PDU 1042 Figure 15. Inactivity Process 1044 3.3 Connection Process, the Initiator is Server, the Target is Client 1046 3.3.1 Initiator side 1048 The Initiator MUST transmit a SYMM PDU. 1050 If the Initiator receives a SYMM then it sends a SYMM. 1052 If the Initiator receives an UI PDU, with the DSAP set to a well- 1053 known value that identifies the TLS service, then the service data 1054 unit transported by the UI is stored in the reception buffer. 1056 If the DSAP value is incorrect the Initiator transmits a DM PDU with 1057 a reason code. 1059 3.3.2 Target side 1061 The Target allocates an ephemeral SSAP ranging between 16 and 31, 1062 and sends a SYMM. 1064 The DSAP of UI PDU will use the allocated SSAP, and DSAP set to a 1065 well-known value that identifies the TLS service. 1067 3.3.3 Connection choreography 1069 Initiator Target 1070 | | 1071 socket= acceptllcp(TLS-SAP) socket=connectllcp(TLS-SAP) 1072 | | 1073 | DSAP=well-known value 1074 | Allocate Ephemeral SSAP 1075 | | 1076 | Done 1077 | | 1078 | sendllcp() 1079 | | 1080 Send SYMM ------------------> Receive SYMM 1081 | | 1082 Receive UI <------------------ Send UI 1083 Check DSAP | 1084 | | 1085 Done 1087 Figure 15. Connection Choreography 1089 3.4 Connection Process, the Initiator is Client, the Target is Server 1091 3.4.1 Initiator side 1093 The initiator allocates an ephemeral SSAP ranging between 16 and 31, 1094 and sends a SYMM. 1096 The DSAP of UI PDU will use the allocated SSAP, and DSAP set to a 1097 well-known value that identifies the TLS service. 1099 3.4.2 Target side 1101 If target receives a SYMM, then it sends A SYMM. 1103 If the Target receives an UI PDU, with the DSAP set to a well-known 1104 value that identifies the TLS service, then the service data unit 1105 transported by the UI is stored in the reception buffer. 1107 Upon success the Target sends a SYMM. 1109 If the DSAP value is incorrect the Initiator transmits a DM PDU with 1110 a reason code. 1112 3.4.3 Connection choreography 1114 Initiator Target 1115 | | 1116 socket= connectllcp(TLS-SAP) socket= acceptllcp(TLS-SAP) 1117 | | 1118 DSAP=well-known value | 1119 Allocate Ephemeral SSAP | 1120 | | 1121 Done | 1122 | | 1123 Sendllcp() | 1124 | | 1125 Send UI -------------------> Receive UI 1126 receive SYMM <------------------ Send SYMM 1127 | | 1128 Done Done 1130 Figure 16. Connection Choreography 1132 3.5 Disconnection Process 1134 Due to the ephemeral nature of P2P NFC session, the disconnection 1135 process MAY be unavailable. Nerveless it SHOULD be used for a 1136 graceful closing of a TLS session. The Disconnection Process is 1137 initiated by the Initiator or the Target. 1139 3.5.1 Disconnection initiated by the Initiator 1141 The Initiator MUST send a DM PDU 1143 The Target receives the DM PDU. 1145 The Target sends a SYMM or a DM PDU. 1147 3.5.2 Disconnection initiated by the Target 1149 If the Target receives a DM PDU, then it sends the DM or the SYMM 1150 PDU. 1152 Else the Target sends the DM PDU. 1154 3.5.3 Disconnection choreography 1156 Initiator Target 1157 | | 1158 closellcp(socket) | 1159 | | 1160 Send DM -----------------> Receive DM 1161 | | 1162 Receive SYMM or DM <---------------- Send SYMM or DM 1163 | | 1164 Done Done 1166 Figure 17. Disconnection initiated by the Initiator 1168 Initiator Target 1169 | | 1170 | closellcp(socket) 1171 | | 1172 Send SYMM -------------> Receive LLCP PDU 1173 | | 1174 Receive DM <------------ Send DM 1175 | | 1176 Done Done 1178 Figure 18. Disconnection initiated by the Target 1180 3.6 Sending Process 1182 The data transmission is managed by the 1183 sendllcp(SOCKET s, char *buffer, int length) 1184 procedure. 1186 3.6.1 Initiator side 1188 The buffer to be transmitted is segmented in LLCP UI packets. 1190 Initiator Target 1191 | | 1192 Sendllcp(buffer) recvllcp() 1193 | | 1194 Send UI PDU -----------------> Receive UI PDU 1195 Receive SYMM <----------------- Send SYMM 1196 | | 1197 Send UI PDU -----------------> Receive UI PDU 1198 Receive SYMM <----------------- Send SYMM 1199 | | 1200 Buffer Empty | 1201 | 1202 Done 1204 Figure 19. Sending Process, Initiator side. 1206 The following loop is performed 1208 - The Initiator sends an UI PDU 1209 - The initiator receive a SYMM PDU 1211 3.6.2 Target side 1213 The Target switches to the sending process, managed by the 1214 sendllcp() procedure. 1216 The Target MUST receive a SYMM PDU. 1218 The buffer to be sent is segmented in UI PDUs. 1220 The following loop is performed 1222 - The Target sends an UI PDU 1223 - The Target receives a SYMM PDU 1225 When the buffer is empty a last SYMM is sent. 1227 Initiator Target 1228 | | 1229 recvllcp() sendllcp(buffer) 1230 | | 1231 Send SYMM --------> Receive SYMM 1232 | | 1233 Receive UI <------- Send UI 1234 | | 1235 Send SYMM --------> Receive SYMM 1236 | | 1237 Receive UI <------- Send UI 1238 | Buffer Empty 1239 | | 1240 Receive SYMM <------- Send SYMM 1241 | | 1242 | Done 1244 Figure 20. Sending Process, Target side. 1246 3.7 Receiving Process 1248 The Receiving process is handled by the 1249 recvllcp(SOCKET s, char *buffer, int length) 1250 procedure, which manages a reception buffer. 1252 3.7.1 Initiator side 1254 A1) If the reception buffer is empty, the Initiator sends a SYMM 1255 PDU. This PDU starts the Target receiving process. The expected PDU 1256 received from the Target is either an UI PDU or a SYMM PDU 1257 (notifying an ephemeral inactivity state). 1259 B1) If the reception buffer stores enough data, then the size 1260 requested by the recvllcp() procedure is returned. If the buffer 1261 gets empty after this operation, the SYMM PDU SHOULD be sent to the 1262 Target. The PDU received from the Target is either an UI PDU or a 1263 SYMM PDU. 1265 B2) Else, while there is not enough data in the buffer, the 1266 following loop is performed 1267 - Send SYMM 1268 - Receive UI PDU 1270 B2.1) at this end of this loop the size requested by the recvllcp() 1271 procedure is returned. If the buffer gets empty after this 1272 operation, the SYMM PDU SHOULD be sent to the Target. The PDU 1273 received from the Target is either an UI PDU or a SYMM PDU. 1275 In B1 and B2.1 a SYMM PDU SHOULD be sent when the reception buffer 1276 gets empty. This rule avoids un-needed transition to the IP process. 1277 It is a "double checking" of the empty buffer event. 1279 Initiator Target 1280 | | 1281 buffer empty sendllcp() 1282 | | 1283 recvllcp() ===> Send SYMM --------> Receive SYMM 1284 | | 1285 Receive UI <------- Send UI PDU 1286 enough data <=== | | 1287 | | 1288 recvllcp() ===> | | 1289 enough data <=== | | 1290 buffer empty | 1291 | | 1292 Send SYMM --------> Receive SYMM 1293 Receive UI <-------- Send UI 1294 | | 1295 Send SYMM -------> Receive SYMM 1296 | | 1297 Receive UI <------- Send UI PDU 1298 | | 1299 recvllcp() ===> | | 1300 enough data <=== | | 1301 | | 1302 recvllcp() ===> | | 1303 Send SYMM -------> Receive SYMM 1304 | | 1305 Receive UI <------- Send UI PDU 1306 | | 1307 Send SYMM -------> Receive SYMM 1308 | | 1309 Receive UI <------- Send UI PDU 1310 enough data <=== | | 1311 buffer empty Done 1312 | | 1313 | Inactivity Process 1314 | | 1315 Send SYMM --------> Receive SYMM 1316 Receive SYMM <-------- Send SYMM 1317 | | 1318 Done Done 1320 Figure 21. Receiving Process, Initiator side. 1322 3.7.2 Target side 1324 A1) If the reception buffer stores enough data, then the size 1325 requested by the recvllcp() procedure is returned. 1327 B1) Else, while there is not enough data in the buffer, the 1328 following loop is performed 1329 - Receive UI PDU 1330 - Send SYMM PDU 1332 Initiator Target 1333 | | 1334 Sendllcp(buffer) buffer empty 1335 | | 1336 | | <=== recvllcp() 1337 | | 1338 Send UI PDU -----------> Receive UI PDU 1339 | | 1340 Receive SYMM <------------ Send SYMM 1341 | | 1342 | | ===> enough data 1343 | | 1344 | | <=== recvllcp() 1345 | | ===> enough data 1346 | | 1347 | buffer empty 1348 | | 1349 | | <=== recvllcp() 1350 | | 1351 Send UI PDU ----------> Receive UI PDU 1352 | | 1353 Receive SYMM <----------- Send SYMM 1354 | | 1355 Send UI -----------> Receive UI PDU 1356 | | 1357 Receive SYMM <------------ Send SYMM 1358 | | 1359 Done | ===> enough data 1360 | buffer empty 1361 | | 1362 | | 1363 Done 1365 Figure 22. Receiving Process, Target side. 1367 4 Example of LLCPS session, connected mode 1369 4.1 Protocol Activation and Parameters Selection 1371 4.1.1 Initiator ATR-REQ 1373 Raw-data: 1374 5C A9 BE E1 C0 35 A0 BF 16 0F 00 00 00 02 46 66 1375 6D 01 01 10 03 02 00 01 04 01 01 10 64 1377 NFCID3i= 5C A9 BE E1 C0 35 A0 BF 16 0F 1378 DIDi (Initiator ID) = 00 1379 BSi= 00 1380 BRi= 00 1381 PPi= 02, 64 bytes of Transport Data, Gt bytes available 1382 Magic Bytes: 46666d 1383 Option: Version, Major=1, Minor=0 1384 Option: WKS: Well-Known Service List 0x0001 1385 Option: LTO: Link TimeOut 0x64 (1000 ms) 1387 4.1.2 Target ATR-RESP 1389 Raw-Data: 1390 AA 99 88 77 66 55 44 33 22 11 00 00 00 09 03 46 1391 66 6D 01 01 10 03 02 00 01 04 01 64 1393 NFCID3t= AA 99 88 77 66 55 44 33 22 11 1394 DIDt (Target ID)= 00 1395 BSt= 00 1396 BRt= 00 1397 TO= 09, WT= 6363 ms 1398 PPt= 03, 64 bytes of Transport Data, NAD available, Gt bytes 1399 available 1400 Magic Bytes: 46666d 1401 Option: Version, Major=1, Minor=0 1402 Option: WKS: Well-Known Service List 0x0001 1403 Option: LTO: Link TimeOut 0x64 (1000 ms) 1405 4.2 LLCP connection 1407 Initiator: Sending SYMM, ssap=0 dsap=0 1408 Tx-i: 00 00 1409 Target: Sending CONNECT, ssap=27 dsap=1, option=SN("com.ietf.tls") 1410 Rx_i: 05 1B 06 0C 63 6F 6D 2E 69 65 74 66 2E 74 6C 73 1411 Initiator: Sending ConnectionComplete, ssap=16 dsap=27 1412 Tx-i: 6D 90 1413 Target: Sending SYMM, ssap=0 dsap=0 1414 Rx-i: 00 00 1415 4.3 Target: sending Client Hello 1417 RecvLLCP Initiator: request size=5, buffer empty, sending SYMM 1418 Initiator: Sending SYMM, ssap=0 dsap=0 1419 Tx-i: 00 00 1421 SendLLCP Target: request size=82 bytes, Waiting for SYMM 1422 Target: Receiving SYMM, ssap=0 dsap=0 1423 Target: Sending INFORMATION, ssap=27 dsap=16 Nr=0, Ns=0 1424 Rx-i: 43 1B 00 16 03 01 00 4D 01 00 00 49 03 01 50 1A 1425 A9 6B 82 55 1C B5 AD FF BC 87 21 66 5F B5 98 41 1426 9E 17 33 39 45 F9 78 86 46 D6 F6 75 51 10 20 E7 1427 0A 41 FE 8C F9 A0 38 D3 28 72 E8 04 7E C2 37 22 1428 05 13 24 AA DE 2F 6B 67 4C 19 CE A5 7D A0 86 00 1429 02 00 04 01 00 1431 RecvLLCP_Initiator: request size=5 bytes, buffer=82 bytes 1432 RecvLLCP_Initiator: request size=77 bytes, buffer=77 bytes 1433 RecvLLCP_Initiator: buffer empty, sending RR(1), ssap=16 dsap=27 1434 Tx-i: 6F 50 01 1436 SendLLCP_Target: Receiving RR(1), ssap=16 dsap=27 1437 SendLLCP_Target: empty buffer, Done, Sending SYMM 1438 Target: Sending SYMM, ssap=0 dsap=0 1440 Initiator: Receiving SYMM ssap=0 dsap=0 1441 Rx-i: 00 00 1443 4.4 Inactivity Process 1445 Initiator: Sending SYMM, ssap=0 dsap=0 1446 Tx-i: 00 00 1448 RecvLLCP Target: request size=5 bytes, buffer empty 1449 Target: Receiving SYMM, ssap=0 dsap=0 1450 Target: Sending SYMM, ssap=0 dsap=0 1452 Initiator: Receiving SYMM, ssap=0 dsap=0 1453 Rx-i: 00 00 1455 4.5 Server: sending Server Hello 1457 SendLLCP_Initiator: request size=122 bytes 1458 Initiator: Sending INFORMATION, ssap=16 dsap=27 Nr=1 Ns=0 1459 Tx-i: 6F 10 01 16 03 01 00 4A 02 00 00 46 03 01 50 1A 1460 A9 6B 6C 0E 31 E1 F3 0E CD 18 E7 6F 81 BF 5F 3C 1461 FD DE 00 4C A4 12 AE DC DF E4 FF 82 09 5E 20 E7 1462 0A 41 FE 8C F9 A0 38 D3 28 72 E8 04 7E C2 37 22 1463 05 13 24 AA DE 2F 6B 67 4C 19 CE A5 7D A0 86 00 1464 04 00 14 03 01 00 01 01 16 03 01 00 20 83 18 D1 1465 E3 BC 3A 94 26 91 3D FC F3 8E 01 46 5E 52 8E 67 1466 A2 66 FC 5F D5 89 78 59 66 14 BA D3 B0 1468 RecvLLCP_Target: Receiving INFORMATION, ssap=16 dsap=27 Nr=1 Ns=0 1469 RecvLLCP_Target: sending RR(1), ssap=27 dsap=16 1470 RecvLLCP_Target: request size=74 bytes 1471 RecvLLCP_Target: request size=5 bytes 1472 RecvLLCP_Target: request size=1 byte 1474 SendLLCP Initiator: Receiving RR(1), ssap=27 dsap=16 1475 Rx-i: 43 5B 01 1476 SendLLCP_Initiator: buffer empty, Done 1478 RecvLLCP_Target: request size=5 bytes 1479 RecvLLCP_Target: request size=32 bytes, Done, empty buffer 1481 4.6 LLCP Inactivity Process 1483 RecvLLCP_Initiator: request size=5, empty buffer, sending SYMM 1484 Initiator: Sending SYMM, ssap=0 dsap=0 1485 Tx-i: 00 00 1487 Target: Receiving SYMM, ssap=0 dsap=0 1488 Target: Sending SYMM, ssap=0 dsap=0 1490 Initiator: Receiving SYMM ssap=0 dsap=0 1491 Rx-i: 00 00 1493 4.7 Client: sending Client Finished 1495 Initiator: Receiving SYMM ssap=0 dsap=0 1496 Tx-i: 00 00 1498 SendLLCP_Target: request size=43 bytes, Waiting for SYMM 1499 Target: Receiving SYMM, ssap=0 dsap=0 1500 Target: Sending INFORMATION, ssap=27 dsap=16 Nr=1, Ns=1 1501 Rx-i: 43 1B 11 14 03 01 00 01 01 16 03 01 00 20 57 DD 1502 DE 29 9E E4 EF DD C5 18 87 50 C6 C7 B9 56 AD FA 1503 EF 65 B2 24 48 04 2E FE 7D BD 97 E1 F3 3A 1505 Initiator: Receiving INFORMATION, ssap=27 dsap=16 Nr=1, Ns=1 1506 RecvLLCP_Initiator: request size= 5 bytes, buffer=43 bytes 1507 RecvLLCP_Initiator: request size= 1 bytes, buffer=38 bytes 1508 RecvLLCP_Initiator: request size= 5 bytes, buffer=37 bytes 1509 RecvLLCP_Initiator: request size=32 bytes, buffer=32 bytes 1510 RecvLLCP_Initiator: empty buffer, sending RR(2) 1511 Initiator: Sending RR(2), ssap=16 dsap=27 1512 Tx-i: 6F 50 02 1514 Target: Receiving RR(2), ssap=16 dsap=27 Nr=2 1515 SendLLC_Target: empty buffer, Done, sending SYMM 1516 Target: Sending SYMM, ssap=0 dsap=0 1518 Initiator: Receiving SYMM ssap=0 dsap=0 1519 Rx-i: 00 00 1521 4.8 Exchanging Data 1523 4.8.1 Sending data from client to server 1525 RecvLLCP_Initiator: request size=5 bytes, empty buffer, sending SYMM 1526 Initiator: Sending SYMM, ssap=0 dsap=0 1527 Tx-i: 00 00 1529 Target: Receiving SYMM, ssap=0 dsap=0 1530 SendLLCP_Target: sending 27 bytes 1531 Target: Sending INFORMATION, ssap=27 dsap=16 Nr=1, Ns=2 1533 Initiator: Receiving INFORMATION, ssap=27 dsap=16 Nr=1, Ns=2 1534 Rx-i: 43 1B 21 17 03 01 00 16 C2 D5 18 CB 0D AB 44 E5 1535 0F 25 DB 83 6D 26 B7 74 E7 90 EF 33 8C FE 1536 RecvLLCP_Initiator: request size= 5 bytes, buffer=27 bytes 1537 RecvLLCP_Initiator: request size=22 bytes, buffer=22 bytes 1538 Initiator: Sending RR(3), ssap=16 dsap=27 1539 Tx-i: 6F 50 03 1541 Target: Receiving RR(3), ssap=16 dsap=27 1542 SendLLC_Target: empty buffer, Done, sending SYMM 1543 Target: Sending SYMM, ssap=0 dsap=0 1545 Initiator: Receiving SYMM ssap=0 dsap=0 1546 Rx-i: 00 00 1548 4.8.2 Sending data from server to client 1550 SendLLCP Initiator: request size=27 bytes 1551 Initiator: Sending INFORMATION, ssap=16 dsap=27 Nr=3 Ns=1 1552 Tx-i: 6F 10 13 17 03 01 00 16 DC 82 FE B9 EA 1C 63 5C 1553 AC 8C FE C9 A2 4F 8A FD 54 EE 18 F5 DB 30 1555 RecvLLCP_Target: request size= 5 bytes 1556 Target: Receiving INFORMATION, ssap=16 dsap=27 Nr=3 Ns=1 1557 RecvLLCP_Target: sending RR(2) 1558 Target: Sending RR(2), ssap=27 dsap=16 1559 RecvLLCP_Target: request size=22 bytes, buffer=22 bytes, Done 1561 Initiator: Receiving RR(2), ssap=27 dsap=16 1562 Rx-i: 43 5B 02 1563 SendLLCP Initiator: empty buffer, Done 1564 4.9 Closing TLS session, initiated by the Initiator 1566 Initiator: Sending DISC, ssap=16 dsap=27 1567 Tx-i: 6D 50 1569 Target: Receiving DISC, ssap=16 dsap=27 1570 Target: Sending DM, ssap=27 dsap=16 1572 Initiator: Receiving DM, ssap=27 dsap=16 1573 Rx-i: 41 DB 00 1575 5 Example of LLCPS session, Connectionless mode 1577 5.1 Protocol Activation and Parameters Selection 1579 5.1.1 Initiator ATR-REQ 1581 Raw-data: 1582 5C A9 BE E1 C0 35 A0 BF 16 0F 00 00 00 02 46 66 1583 6D 01 01 10 03 02 00 01 04 01 01 10 64 1585 NFCID3i= 5C A9 BE E1 C0 35 A0 BF 16 0F 1586 DIDi (Initiator ID) = 00 1587 BSi= 00 1588 BRi= 00 1589 PPi= 02, 64 bytes of Transport Data, Gt bytes available 1590 Magic Bytes: 46666d 1591 Option: Version, Major=1, Minor=0 1592 Option: WKS: Well-Known Service List 0x0001 1593 Option: LTO: Link TimeOut 0x64 (1000 ms) 1595 5.1.2 Target ATR-RESP 1597 Raw-Data: 1598 AA 99 88 77 66 55 44 33 22 11 00 00 00 09 03 46 1599 66 6D 01 01 10 03 02 00 01 04 01 64 1601 NFCID3t= AA 99 88 77 66 55 44 33 22 11 1602 DIDt (Target ID)= 00 1603 BSt= 00 1604 BRt= 00 1605 TO= 09, WT= 6363 ms 1606 PPt= 03, 64 bytes of Transport Data, NAD available, Gt bytes 1607 available 1608 Magic Bytes: 46666d 1609 Option: Version, Major=1, Minor=0 1610 Option: WKS: Well-Known Service List 0x0001 1611 Option: LTO: Link TimeOut 0x64 (1000 ms) 1612 5.2 LLCP connection 1614 Initiator: Sending SYMM, ssap=0 dsap=0 1615 Tx-i: 00 00 1617 Target: Setting DSAP to 13 (well known-value), setting ephemeral 1618 SSAP to 27 1620 5.3 Client Hello 1622 Target: Receiving SYMM, ssap=0 dsap=0 1623 Target: Sending UI, dsap=13 ssap=27, 82 bytes 1625 Initiator: Receiving UI, ssap=27 dsap=13 1626 Rx-i: 34 DB 16 03 01 00 4D 01 00 00 49 03 01 51 09 2E 1627 3A CC 72 28 FE F5 D3 6F A8 D9 E7 55 67 6C 3B C3 1628 7C 6C AF 18 1A 7F C6 81 1A 9D 0F 3D F8 20 04 E2 1629 26 36 24 92 33 68 48 C7 34 A4 44 E3 70 8C 6C 11 1630 44 53 54 20 B1 A9 3D 47 A8 3F E5 C5 D5 D2 00 02 1631 00 04 01 00 90 00 1633 RecvLLC Initiator: request size=5 buffer size=82 1634 RecvLLC Initiator: request size=77 buffer size=77 1635 RecvLLC Initiator: buffer empty 1637 Initiator: Sending SYMM, ssap=0 dsap=0 1638 Tx-i: 00 00 1640 Target: Receiving SYMM, ssap=0 dsap=0 1641 Target: Sending SYMM, ssap=0,dsap=0 1643 Rx-i: 00 00 1645 5.4 Server Hello 1647 SendLLC Initiator: request size=122 1648 Initiator: Sending UI, ssap=13 dsap=27 1650 Tx-i: 6C CD 16 03 01 00 4A 02 00 00 46 03 01 51 09 2E 1651 3A 23 03 7D 28 AF D1 71 B4 0F 60 ED 3D A0 86 4B 1652 67 36 A8 80 AB 34 78 21 63 1B D8 F5 81 20 04 E2 1653 26 36 24 92 33 68 48 C7 34 A4 44 E3 70 8C 6C 11 1654 44 53 54 20 B1 A9 3D 47 A8 3F E5 C5 D5 D2 00 04 1655 00 14 03 01 00 01 01 16 03 01 00 20 B9 0C 3F E8 1656 C8 48 F3 8B 1A 1C 59 01 6C C9 A0 7F 33 FB E9 A3 1657 1E 9E 25 B8 FA AE FE 77 06 51 3D E4 1659 Target: Receiving UI, ssap=13 dsap=27, 122 bytes 1661 RecvLLC Target: request size= 5, buffer size= 122 1662 RecvLLC Target: request size=74, buffer size= 117 1663 RecvLLC Target: request size= 5, buffer size= 43 1664 RecvLLC Target: request size= 1, buffer size= 42 1665 RecvLLC Target: request size= 5, buffer size= 37 1666 RecvLLC Target: request size=32, buffer size= 32 1667 RecvLLC Target: empty buffer 1669 Target: Sending SYMM, ssap=0 dsap=0 1671 Initiator: Receiving SYMM, ssap=0 dsap=0 1672 Rx-i: 00 00 1674 5.5 Client Finished 1676 Initiator: Sending SYMM, ssap=0 dsap=0 1677 Tx-i: 00 00 1679 Target: Receiving SYMM, ssap=0 dsap=0 1681 SendLLC Target: sending 43 bytes 1682 Target: Sending UI, ssap=27 dsap=13, 43 bytes 1684 Initiator: Receiving UI, ssap=27 dsap=13, 43 bytes 1686 Rx-i: 34 DB 14 03 01 00 01 01 16 03 01 00 20 7E 92 D1 1687 D1 78 C4 39 2D 8D 11 9A DF 0F 0B E5 7C 33 BA DC 1688 3D B0 33 CD 5E 27 BE A4 6C 62 78 F3 D8 1690 RecvLLC Initiator: request size=5 buffer size=43 1691 RecvLLC Initiator: request_size=1 buffer size=38 1692 RecvLLC Initiator: request_size=5 buffer_size=37 1693 RecvLLC Initiator: request_size=32 buffer size=32 1694 RecvLLC_Initiator: buffer empty 1696 Initiator: Sending SYMM, ssap=0 dsap=0 1697 Tx-i: 00 00 1699 Target: Receiving SYMM, ssap=0 dsap=0 1700 Target: Sending SYMM, ssap=0,dsap=0 1701 Rx-i: 00 00 1703 5.6 Exchanging Data 1705 5.6.1 Sending data from client to server 1707 Initiator: Sending SYMM, ssap=0 dsap=0 1708 Tx-i: 00 00 1710 Target: Receiving SYMM, ssap=0 dsap=0 1711 Target: Sending UI, ssap=27 dsap=13, 27 bytes 1712 Rx-i: 34 DB 17 03 01 00 16 EA 91 72 8A DA 5A DD F0 C7 1713 6A E0 82 15 B4 8F 5E 72 F6 BE 64 9D 0E 1715 Initiator: Receiving UI, ssap=27 dsap=13, 27 bytes 1717 SendLLC Initiator: request size= 5, buffer size=32 1718 SendLLC Initiator: request size=27, buffer size=27 1719 SendLLC Initiator: buffer empty 1721 Initiator: Sending SYMM, ssap=0 dsap=0 1722 Tx-i: 00 00 1724 Target: Sending SYMM, ssap=0,dsap=0 1725 Initiator: Receiving SYMM, ssap=0 dsap=0 1727 Rx-i: 00 00 1729 5.6.2 Sending data from server to client 1731 Initiator: Sending UI, ssap=13 dsap=27, 27 bytes 1733 Tx-i: 6C CD 17 03 01 00 16 93 48 F4 7F 67 F8 6E A1 94 1734 15 BB AF D1 BD CA 2D AE 48 0B A6 9B 9D 1736 Target: Receiving UI, ssap=13 dsap=27, 27 bytes 1737 Target: Sending SYMM, ssap=0,dsap=0 1739 RecvLLC Target: request size= 5, buffer size=32 1740 RecvLLC Target: request size=27, buffer size=27 1741 RecvLLC Target: buffer empty 1743 Initiator: Receiving SYMM, ssap=0 dsap=0 1744 Rx-i: 00 00 1746 5.7 End of Session 1748 Initiator: Sending DM, ssap=0 dsap=0 1749 Target: Receiving DM, ssap=0 dsap=0 1750 Target: Sending SYMM, ssap=0 dsap=0 1751 Initiator: Receiving SYMM, ssap=0 dsap=0 1752 6 Security Considerations 1754 To be done. 1756 7 IANA Considerations 1758 8 References 1760 8.1 Normative References 1762 [TLS 1.0] Dierks, T., C. Allen, "The TLS Protocol Version 1.0", RFC 1763 2246, January 1999 1765 [TLS 1.1] Dierks, T., Rescorla, E., "The Transport Layer Security 1766 (TLS) Protocol Version 1.1", RFC 4346, April 2006 1768 [TLS 1.2] Dierks, T., Rescorla, E., "The Transport Layer Security 1769 (TLS) Protocol Version 1.1", draft-ietf-tls-rfc4346-bis-10.txt, 1770 March 2008 1772 [RFC 5216] B. Aboba, D. Simon, R. Hurst, "EAP TLS Authentication 1773 Protocol" RFC 5216, March 2008. 1775 [ECMA340] "Near Field Communication Interface and Protocol (NFCIP- 1776 1)", Standard ECMA-340, December 2004 1778 [ISO/IEC 18092] "Information technology - Telecommunications and 1779 information exchange between systems - Near Field Communication - 1780 Interface and Protocol (NFCIP-1)", April 2004 1782 [LLCP] "Logical Link Control Protocol", Technical Specification, NFC 1783 ForumTM, LLCP 1.1, June 2011 1785 [SNEP] "Simple NDEF Exchange Protocol", Technical Specification, NFC 1786 ForumTM, SNEP 1.0, August 2011 1788 [NDEF] "NFC Data Exchange Format (NDEF)", Technical Specification 1789 NFC ForumTM, NDEF 1.0, July 2006. 1791 [ISO7816] ISO 7816, "Cards Identification - Integrated Circuit Cards 1792 with Contacts", The International Organization for Standardization 1793 (ISO) 1795 [IEEE 802.2] IEEE Std 802.2, "IEEE Standard for Information 1796 technology Telecommunications and information exchange between 1797 systems Local and metropolitan area networks, Specific requirements, 1798 Part 2: Logical Link Control", 1998 1799 8.2 Informative References 1801 [NPP} "Android NDEF Push Protocol Specification Version 1", February 1802 2011 1804 9 Authors' Addresses 1806 Pascal Urien 1807 Telecom ParisTech 1808 23 avenue d' Italie 1809 75013 Paris Phone: NA 1810 France Email: Pascal.Urien@telecom-paristech.fr