idnits 2.17.1 draft-urien-tls-llcp-11.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 178, 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 January 13 2018 7 Expires: July 2018 9 LLCPS 10 draft-urien-tls-llcp-11.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 July 2018. 48 . 50 Copyright Notice 52 Copyright (c) 2018 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 LLCPS January 2018 67 Table of Contents 69 Abstract........................................................... 1 70 Requirements Language.............................................. 1 71 Status of this Memo................................................ 1 72 Copyright Notice................................................... 2 73 1 Overview......................................................... 5 74 1.1 About the NFC protocol...................................... 5 75 1.2 The LLCP layer.............................................. 7 76 1.3 LLCPS basic guidelines...................................... 9 77 2 TLS support over LLCP, Connection-oriented Transport............ 10 78 2.1 Peer To Peer Link Establishment............................ 10 79 2.3 Connection Process, the Initiator is Server, the Target is 80 Client......................................................... 13 81 2.3.1 Initiator side ...................................... 13 82 2.3.2 Target side ......................................... 14 83 2.3.3 Connection choreography ............................. 14 84 2.4 Connection Process, the Initiator is Client, the Target is 85 Server......................................................... 14 86 2.4.1 Initiator side ...................................... 14 87 2.4.2 Target side ......................................... 15 88 2.4.3 Connection choreography ............................. 15 89 2.5 Disconnection Process...................................... 15 90 2.5.1 Disconnection initiated by the Initiator ............ 15 91 2.5.2 Disconnection initiated by the Target ............... 15 92 2.5.3 Disconnection choreography .......................... 16 93 2.6 Sending Process............................................ 16 94 2.7 Receiving Process.......................................... 18 95 3 TLS support over LLCP, Connectionless Transport................. 21 96 3.1 Peer To Peer Link Establishment............................ 23 97 3.2 Inactivity Process......................................... 24 98 3.3 Connection Process, the Initiator is Server, the Target is 99 Client......................................................... 24 100 3.3.1 Initiator side ...................................... 24 101 3.3.2 Target side ......................................... 25 102 3.3.3 Connection choreography ............................. 25 103 3.4 Connection Process, the Initiator is Client, the Target is 104 Server......................................................... 25 105 3.4.1 Initiator side ...................................... 25 106 3.4.2 Target side ......................................... 25 107 3.4.3 Connection choreography ............................. 26 108 3.5 Disconnection Process...................................... 26 109 3.5.1 Disconnection initiated by the Initiator ............ 26 110 3.5.2 Disconnection initiated by the Target ............... 26 111 3.5.3 Disconnection choreography .......................... 27 112 3.6 Sending Process............................................ 27 113 3.7 Receiving Process.......................................... 29 114 4 Example of LLCPS session, connected mode........................ 32 115 4.1 Protocol Activation and Parameters Selection............... 32 116 4.1.1 Initiator ATR-REQ ................................... 32 117 4.1.2 Target ATR-RESP ..................................... 32 118 LLCPS January 2018 120 4.2 LLCP connection............................................ 32 121 4.3 Target: sending Client Hello............................... 33 122 4.4 Inactivity Process......................................... 33 123 4.5 Server: sending Server Hello............................... 33 124 4.6 LLCP Inactivity Process.................................... 34 125 4.7 Client: sending Client Finished............................ 34 126 4.8 Exchanging Data............................................ 35 127 4.8.1 Sending data from client to server .................. 35 128 4.8.2 Sending data from server to client .................. 35 129 4.9 Closing TLS session, initiated by the Initiator............ 36 130 5 Example of LLCPS session, Connectionless mode................... 36 131 5.1 Protocol Activation and Parameters Selection............... 36 132 5.1.1 Initiator ATR-REQ ................................... 36 133 5.1.2 Target ATR-RESP ..................................... 36 134 5.2 LLCP connection............................................ 37 135 5.3 Client Hello............................................... 37 136 5.4 Server Hello............................................... 37 137 5.5 Client Finished............................................ 38 138 5.6 Exchanging Data............................................ 38 139 5.6.1 Sending data from client to server .................. 38 140 5.6.2 Sending data from server to client .................. 39 141 5.7 End of Session............................................. 39 142 6 Security Considerations......................................... 40 143 7 IANA Considerations............................................. 40 144 8 References...................................................... 40 145 8.1 Normative References....................................... 40 146 8.2 Informative References..................................... 41 147 9 Authors' Addresses.............................................. 41 148 LLCPS January 2018 150 1 Overview 152 1.1 About the NFC protocol 154 The Near Field Communication protocol (NFC) is based on standards 155 such as [ECMA340] or [ISO/IEC 18092]. It uses the 13,56 MHz 156 frequency, with data rates ranging from 106 To 848 kbps. The working 157 distance between two nodes is about a few centimeters, with 158 electromagnetic fields ranging between 1 and 10 A/M. 160 There are two classes of working operations: 162 - Reader/Writer and Card Emulation. A device named "Reader" feeds 163 another device called "Card", thanks to a 13,56 MHz electromagnetic 164 field coupling. This mode is typically used with [ISO7816] 165 contactless smartcards or with NFC RFIDs. 167 - Peer To Peer (P2P). Two devices, the "Initiator" and the "Target" 168 establish a NFC communication link. In the "Active" mode these two 169 nodes are managing their own energy resources. In the "Passive" mode 170 the Initiator powers the Target via a 13,56 MHz electromagnetic 171 field coupling. 173 This draft focuses on P2P security, which is required by many 174 applications, targeting access control, transport, or other Internet 175 of Things (IoT) items. Although the NFC protocol enables data 176 exchange at small physical distances, it doesn't support 177 standardized security features providing privacy or integrity. Thus, 178 protocols such as [SNEP] or [NPP], whose goal is to push NDEF [NDEF] 179 contents, are not today secured. In this draft we define a profile 180 for TLS support in P2P operations. 182 A P2P session (see figure 1) occurs in four logical phases: 184 1) Initialization and Anti-collision. The Initiator periodically 185 sends a request packet (and therefore generates a RF field), which 186 is acknowledged by a Target response packet. Because several Targets 187 may be located near the Initiator, an anti-collision mechanism is 188 managed by the Initiator in order to establish a session with a 189 single Target. 190 2) Protocol Activation and Parameters Selection. The Initiator 191 starts a logical session with a detected Target by sending a ATR-REQ 192 (Attribute-Request) message, which is confirmed by a Target ATR-RESP 193 (Attribute-Response) message. These messages fix the device IDs 194 (DIDi, Device ID Initiator and DIDt, Device ID Target) used in 195 further packet exchanges. Optional information fields (Gi for the 196 Initiator, and Gt for the Target) identify the protocol to be used 197 over the MAC level; in this document it is assumed that the LLCP 198 [LLCP] (Logical Link Control Protocol) protocol is selected by the 199 Gi and Gt bytes. Optionally some parameters are negotiated by 200 additional packets. 202 LLCPS January 2018 204 3) Data Exchange. Frames are exchanged via the DEP (Data Exchange 205 Protocol) protocol. DEP works with DEP-REQ (DEP-Request) transmitted 206 by the Initiator and DEP-RESP (DEP-Response) delivered by the 207 Target. DEP provides error detection and recovery. It uses small 208 data unit size (from 64 to 256 bytes); however it supports a 209 chaining mode for larger sizes. DEP frames typically transport LLCP 210 packets, and provide an error free service 211 4) De-Activation. The Initiator may deactivate the Target by sending 212 a RLS-REQ (Release Request) message acknowledged by a RLS-RESP 213 (Release Response). 215 Usually, and for practical reasons, P2P sessions are established 216 between a unique Target and an Initiator, for example a mobile phone 217 and another NFC device. They are automatically started when the 218 distance between the two NFC modes is sufficiently small. The MAC 219 link may be broken at any time, as soon as the distance disables 220 radio operations. 222 Initiator Target 223 | | 224 |<------ (1) Initialization and Anti-Collision ------->| 225 | | 226 |<- (2) Protocol Activation and Parameters Selection ->| 227 | ------------------- ATR-REQ -----------------------> | 228 | <------------------ ATR-RESP ----------------------- | 229 | | 230 |<---------------- (3) Data Exchange ----------------->| 231 | LLCP packets over DEP frames | 232 | TLS over LLCP | 233 | | 234 |<----------------(4) De-Activation ------------------>| 235 | | 237 Figure 1. A NFC P2P Session 239 Due to the dissymmetry of the DEP protocol (see figure 2), in which 240 the Initiator sends requests and Target returns responses, the NFC- 241 P2P MAC services are dissymmetric on the Initiator and Target sides. 243 - The Initiator delivers Data.Request-i and gets Data.Indication-i. 244 - The Target gets Data.Indication-t and delivers Data.Request-t 246 MAC services implemented by NFC controllers usually support such 247 dissymmetric primitives for Initiator and Target procedures (MAC 248 Data.request-i/t and Data.Indication-i/t). 250 The timeout value (between DEP-REQ and DEP-RESP messages) is deduced 251 from the RWT attribute (Response Waiting Time) returned by the 252 Target in the ATR-RESP message. RWT ranges between 0,6 ms and 9,9 253 ms. It may be extended to the RWT-INT by a factor RTOX (RWT-INT = 254 RTOX x RWT) between 1 and 60, so the maximum value is about 6s. 256 LLCPS January 2018 258 Initiator Target 259 | | | | 260 | | | | 261 | Data.Request-i --- DEP-REQ --> Data.Indication-t | 262 | | | 263 | RWT-INT ms | 264 | | | 265 Data.Indication-i <---- DEP-RESP --------- Data.Request-t 267 Figure 2. NFC-P2P MAC layer service, based on DEP frames 269 1.2 The LLCP layer 271 The LLCP [LLCP] protocol works like a light LLC [IEEE 802.2] layer. 272 It provides two classes of services, connectionless transport and 273 connection-oriented transport. 275 This draft focuses both on connection-oriented transport, in which 276 TLS services are identified by a Service Name (SN), and on non- 277 connected mode, in which a fix (well-known) Service Access Point 278 (SAP) is used. 280 A LLCP packet (see figure 3) comprises three mandatory fields, DSAP 281 (Destination Service Access Point, 6 bits), SSAP (Source Service 282 Access Point, 6 bits), and PTYPE (Protocol data unit type field, 4 283 bits). 285 An optional sequence field (8 bits) contains two 4 bits number N(S) 286 and N(R) respectively giving the number of the information SDU to be 287 sent and the number of the next information PDU to be received. 289 An optional Information field transports the LLCP payload. 291 <--------------LLCP Header--------------><-LLCP Payload -> 292 | DSAP | PTYPE | SSAP | Sequence | INFORMATION | 293 | 6 bits | 4 bits | 6 bits | 0 or 8 bits | M x 8 bits | 295 Figure 3. Structure of an LLCP packet 297 There are sixteen types of LLCP packets, identified by PTYPE values 298 ranging between 0 and 15. In this draft we use only nine of these 299 PDUs. 301 1) Symmetry (SYMM, PTYPE=0, DSAP=SSAP=0, No Sequence, No 302 Information). This PDU is produced as soon as there is no 303 information to provide. This mechanism avoids timeout at the MAC 304 (DEP) level. SYMM SHOULD be generated after an inactivity period of 305 about LTO/2, where LTO is the link timeout. 307 LLCPS January 2018 309 2) Connect (CONNECT, PTYPE=4, No sequence, Information). This PDU 310 MUST include a SN (service name parameter) that identified the TLS 311 service ("urn:nfc:sn:tls:service"). It uses a DSAP value set to 1 312 (the SAP of the Service Discovery Protocol, SDP) and a SSAP value 313 ranging between 16 and 31. It indicates the connection the well- 314 known service (WKS) SDP (SAP=1), which SHOULD deliver an ephemeral 315 SAP (SAP-client) ranging between 16 and 31. 317 3) Connection Complete (CC, PTYPE=6, No sequence, Optional 318 Information). This PDU notifies the successful connection to the 319 "urn:nfc:sn:tls:service" service. It allocates the SAP (DSAP=SAP- 320 client) to be used for this session identified by the tuple (SAP- 321 server, SAP-client) 323 4) Disconnection (DISC, PTYPE=5, No sequence, No Information). This 324 PDU indicates the disconnection of the (SAP-server, SAP-client) 325 session. Null SAP values MAY be used to notify the disconnection of 326 the LLCP entity. 328 5) Disconnected Mode (DM, TYPE=7, No sequence, one byte of 329 Information). This PDU confirms the disconnection of the (SAP- 330 server, SAP-client) session; one information byte gives the 331 "Disconnected Mode Reasons". Null SAP values notify the 332 disconnection of the LLCP entity. 334 6) Information (INFORMATION, PTYPE=10, Sequence, information). This 335 PDU transport a SDU; N(S) indicates the SDU number, N(R) indicates 336 the next SDU number to be received. In this draft the Receive 337 Windows Size (RW) MUST be set to one, which is the default LLCP 338 value. 340 7) Receive Ready (RR, PTYPE=11, sequence N(R) only, no Information). 341 This PDU is used for the acknowledgment of previously received 342 information PDU. It indicates the next sequence number (N(R)) to be 343 received. 345 8) Receive Not Ready (RNR, PTYPE=12, sequence N(R) only, no 346 Information).This PDU indicates a temporary inability to process 347 subsequent information PDUs. 349 9) Unnumbered Information (UI, PTYPE=3, no Sequence, Optional 350 Information). This PDU is used to transfer service data units to the 351 peer LLC without prior establishment of a data link connection. 353 According to [LLCP] some LLCP functional parameters are updated by 354 LLCP-Parameter attributes exchanged in LLCP packets or in ATR-REQ 355 and ATR-RESP messages. Parameters are encoding according to TLV 356 format, in which Type size is one byte, Length size is one byte and 357 Value is a set of L bytes. In this document we use 6 parameters. 359 LLCPS January 2018 361 1) Version Number (VERSION, T=01h, L=01h, V=10h). In this document 362 this option MUST be included in the general bytes of ATR-REQ and 363 ATR-RESP. 365 2) Maximum Information Unit Extension (MIUX, T=02h, L=02h). This 366 parameter extends the maximum size of the LLCP PDU (MIU), whose 367 default value is 128 bytes, according to the relation: MIU = MIUX + 368 128. The MIUX parameter MAY be inserted in general bytes of ATR-REQ 369 and ATR-RESP, and in LLCP PDUs CONNECT and CC. 371 3) Well-Known Service List (WKS, T=03h, L=02h). This parameter 372 associates a bit to the instance of a well-known LLCP parameter. A 373 typical value is 00001h, indicating the availability of the DSP 374 service. WKS MAY be inserted in general bytes of ATR-REQ and ATR- 375 RESP. 377 4) Link Timeout (LTO, T=04h, L=01h). This parameter indicates the 378 timeout value for the LLCP layer, in multiples of 10ms. LTO MAY be 379 inserted in general bytes of ATR-REQ and ATR-RESP. 381 5) Receive Windows Frame (RW, T=05h, L=01h). This parameter 382 indicates the size of the receive windows, its value ranges between 383 0 and 15. The default value is one, and MUST be set to one according 384 to this document. It MAY be inserted in LLCP PDUs CONNECT or CC. 386 6) Service Name (SN, T=06h). This parameter indicates the name of a 387 service. It MUST be inserted in the CONNECT PDU. In this document 388 its value is set to "urn:nfc:sn:tls:service", where "service" is the 389 application name securely transported by TLS. 391 1.3 LLCPS basic guidelines 393 The TLS protocol is a series of record messages, which MAY be 394 encrypted or integrity-protected. Each record message includes a 395 five bytes prefix that comprises three attributes: 396 - The type (one byte) of the message, 397 - The version (two bytes), 398 - The message length (two bytes). 400 The client and the server exchange RECORD messages whose meaning is 401 deduced from the TLS protocol rules, according to a half-duplex 402 paradigm. Therefore as soon as the beginning of the TLS session is 403 detected, the two TLS entities alternatively send and receive a set 404 of record messages, whose synchronization is handled by the 405 knowledge of TLS protocol. 407 The EAP-TLS protocol [RFC 5216] demonstrates how TLS record messages 408 may be gathered in blocks exchanged according to a half-duplex 409 mechanism. 411 LLCPS January 2018 413 LLCPS specifies the TLS session establishment and release, and the 414 transport of TLS packets in a NFC P2P context. 416 Applications secured by LLCPS are identified by the service name 417 "urn:nfc:sn:tls:service" where "service" is the application name. 419 2 TLS support over LLCP, Connection-oriented Transport 421 In NFC P2P mode the Initiator detects a Target and afterwards starts 422 and manages a data exchange session; it may optionally feeds the 423 Target device. The Initiator has consequently a longer useful life 424 than the Target; it is a legitimate place to host TLS server in a 425 permanent way. 427 However the TLS server MAY be hosted on the Initiator or on the 428 Target side. 430 Each entity manages five exclusive processes 432 - The Connection Process (CP) 433 - The Disconnection Process (DP) 434 - The Sending Process (SP) 435 - The Receiving Process (RP) 436 - The Inactivity Process (IP) 438 The Inactivity Process MAY be started (see figure 4) each time a 439 receiving or sending buffer is empty; in this case it is assumed 440 that the computing time or the delay required before the next 441 input/output operation is greater than the LLCP timeout (LTO). 443 2.1 Peer To Peer Link Establishment 445 As described in section 1, the Initiator periodically probes the 446 presence of a Target. At the end of the "Protocol Activation and 447 Parameters Selection" phase, ATR-REQ and ATR-RESP messages have been 448 exchanged, and LLCP services are available on both Initiator and 449 Target nodes, including in particular the Data-Request-i/t and Data- 450 Indication-i/t primitives. 452 Due to the ephemeral intrinsic nature of an NFC connection, the P2P 453 session may be broken at any time, which implies transmission or 454 reception errors notified by the MAC primitives. 456 As a consequence an LLCP session is assumed to be released at the 457 first MAC error. 459 Once a NFC P2P link is established, TLS server and client software 460 entities are activated. Procedures such as: 462 - SOCKET acceptllcp (char *ServiceName), and 463 - SOCKET connectllcp(char *ServiceName) 464 LLCPS January 2018 466 MAY be used respectively on Initiator and Target sides, in order to 467 get a SOCKET. 469 A SOCKET object supports additional facilities, typically the 470 following procedures: 472 - int sendllcp(SOCKET s, char *buffer, int length) 473 - int recvllcp(SOCKET s, char *buffer, int length) 474 - int closellcp(SOCKET s) 476 which are used for the LLCP session management. 478 LLCPS January 2018 480 Initiator Target 481 | | 482 Connection Process Connection Process 483 | | 484 Send SYMM ---------------> Receive SYMM 485 Receive CONNECT <---------------- Send CONNECT 486 Send CC ----------------> Receive CC 487 Receive SYMM <---------------- Send SYMM 488 | | 489 =========================TLS Session============================ 490 | | 491 Receiving Process Sending Process 492 | | 493 Send SYMM -------------> Receive SYMM 494 Receive INFORMATION <------------ Send INFORMATION 495 Send RR -------------> Receive RR 496 Receive SYMM <------------- Send SYMM 497 | | 498 Inactivity Process Receiving Process 499 | | 500 Send SYMM ------------------> Receive SYMM 501 Receive SYMM <----------------- Send SYMM 502 | | 503 Sending Process | 504 | | 505 Send INFORMATION ---------------> Receive INFORMATION 506 Receive RR <-------------- Send RR 507 | | 508 Receiving Process Inactivity Process 509 | | 510 Send SYMM -------------------> Receive SYMM 511 Receive SYMM <------------------ Send SYMM 512 | | 513 | Receiving Process 514 | | 515 Send SYMM ------------> Receiving SYMM 516 Receive INFORMATION <----------- Send INFORMATION 517 Send RR ------------> Receive RR 518 Receive SYMM <----------- Send SYMM 519 | | 520 ===========================End Of TLS Session===================== 521 | | 522 Inactivity Process Inactivity Process 523 | | 524 Disconnection Process | 525 | | 526 Send DISC -------------------> Receive DISC 527 Receive DM <------------------- Send DM 528 | | 530 Figure 4. Overview of Operations, Connected Mode 531 LLCPS January 2018 533 2.2 Inactivity Process 535 When the LLCP layer detects an inactivity period greater than a 536 given timeout value (see figure 5), it generates a SYMM PDU. 537 Therefore each time a LLCP layer is waiting for a non SYMM PDU, and 538 receives a SYMM PDU, it MUST acknowledge it by sending a SYMM PDU. A 539 maximum number (SYMM-Ct-i/t) of echoed SYMM PDU SHOULD be defined. 541 The Inactivity Process (IP) MAY start between the Receiving Process 542 (RP) and the Sending Process (SP). 544 Upon the reception of an INFORMATION PDU, the packet is stored in 545 the reception buffer, and is acknowledged by a RR PDU. 547 Initiator Target 548 | | 549 +------> LLCP inactivity + <-------------+ 550 | | | | 551 | +----------+-----------+ +------------+-----------+ | 552 | + Inactivity Timeout + + Waiting for a LLCP PDU + | 553 | +----------+-----------+ +------------+-----------+ | 554 | | | | 555 | Send SYMM PDU ----> Reception of a PDU | 556 | | | | | 557 | | |SYMM |Other | 558 | Reception of a PDU <---- |Send SYMM PDU |PDU | 559 | | | | |Excepted| 560 | SYMM| |Other PDU SYMM-Ct-t++ |INFOR- | 561 | SYMM-Ct-i++| |Excepted | |-MATION | 562 +-------------+ +--+INFORMATION +------------|--------+ 563 | | 564 End Of LLCP Inactivity Send a LLCP PDU 566 Figure 5. Inactivity Process 568 2.3 Connection Process, the Initiator is Server, the Target is Client 570 2.3.1 Initiator side 572 The Initiator MUST transmit a SYMM LLCP PDU. 574 The Initiator MUST receive a CONNECT PDU, with DSAP=1, including the 575 SN option, whose value MUST be set to "urn:nfc:sn:tls:service". If 576 the SN value is incorrect the Initiator transmits a DM PDU with a 577 reason code. 579 The Initiator MUST send a CC PDU, with an SSAP ranging between 16 580 and 31. 582 LLCPS January 2018 584 The Initiator SHOULD receive a SYMM PDU. It MAY receive an 585 INFORMATION PDU but this behavior is not recommended, since it 586 complicates the implementation of the acceptllcp (and connectllcp) 587 procedure. 589 2.3.2 Target side 591 The Target MUST wait for the reception of a SYMM PDU 593 The Target MUST send a CONNECT PDU, with DSAP=1 and SSAP ranging 594 between 16 and 31, including the option SN, whose value MUST be set 595 to "urn:nfc:sn:tls:service". 597 The Target MUST receive a CC PDU. 599 The Target SHOULD send a SYMM PDU. It MAY send an INFORMATION PDU 600 but this behavior is not recommended, since it complicates the 601 implementation of the connectllcp (and acceptllcp) procedure. 603 2.3.3 Connection choreography 605 Initiator Target 606 | | 607 socket= acceptllcp() socket=connectllcp() 608 | | 609 Send SYMMM ------------> Receive SYMM 610 | | 611 Receive CONNECT <------------- Send CONNECT, DSAP=1 612 Check SN SN = "urn:nfc:sn:tls:x" 613 | | 614 Send CC --------------> Receive CC 615 Allocate Ephemeral SAP | 616 | | 617 Receive SYMM <-------------- Send SYMM 618 | | 619 Done Done 621 Figure 6. Connection Choreography 623 2.4 Connection Process, the Initiator is Client, the Target is Server 625 2.4.1 Initiator side 627 The Initiator MUST send a CONNECT PDU, with DSAP=1 and SSAP ranging 628 between 16 and 31, including the SN option, whose value MUST be set 629 to "com.ietf.tls. 631 The Initiator MUST receive a CC PDU. 633 LLCPS January 2018 635 2.4.2 Target side 637 The Target MUST receive a CONNECT PDU, with DSAP=1, including the SN 638 option, whose value MUST be set to "urn:nfc:sn:tls:service". If the 639 SN value is incorrect the Initiator transmits a DM PDU with a reason 640 code. 642 The Target MUST send a CC PDU, with an SSAP ranging between 16 and 643 31. 645 2.4.3 Connection choreography 647 Initiator Target 648 | | 649 socket= connectllcp() socket= acceptllcp() 650 | | 651 Send CONNECT, DSAP=1 --------------> Receive CONNECT 652 SN = "urn:nfc:sn:tls:service" Check SN 653 | Allocate Ephemeral SAP 654 | | 655 Receive CC <-------------- Send CC 656 | | 657 | | 658 Done Done 660 Figure 7. Connection Choreography 662 2.5 Disconnection Process 664 Due to the ephemeral nature of P2P NFC session, the disconnection 665 process MAY be unavailable. Nerveless it SHOULD be used for a 666 graceful closing of a TLS session. 668 The Disconnection Process is started by the Initiator or the Target. 670 2.5.1 Disconnection initiated by the Initiator 672 The Initiator MUST send a DISC PDU. 674 The Target receives the DISC PDU. 676 The Target MUST send the DM PDU. 678 The Initiator MUST receive the DM PDU. 680 2.5.2 Disconnection initiated by the Target 682 The Target receives a LLCP PDU. If it receives DISC then it sends 683 DM; else it sends the DISC PDU. 685 LLCPS January 2018 687 The target waits for an LLCP PDU. Upon reception of a LLCP PDU it 688 MUST send the SYMM or the DM PDU. 690 2.5.3 Disconnection choreography 692 Initiator Target 693 | | 694 closellcp(socket) | 695 | | 696 Send DISC --------------> Receive DISC 697 | | 698 Receive DM <-------------- Send DM 699 | | 700 Done 702 Figure 8. Disconnection started by the Initiator 704 Initiator Target 705 | | 706 | closellcp(socket) 707 | | 708 Send SYMM -------------> Receive LLCP PDU 709 | | | 710 | | DISC |Other 711 |<-----------------------+ Send DM |(SYMM) 712 | | Done | 713 |<------------------------------------+Send DISC 714 Receive LLCP PDU | 715 | | | 716 | DM |DISC Receive LLCP PDU 717 | |Send DM | 718 Send DM ---------------------> Receive DM 719 | | 720 | <----------------------------- +Send SYMM 721 | |or DM 722 | Done 723 | | 725 Figure 9. Disconnection started by the Target 727 2.6 Sending Process 729 The data transmission is managed by the sendllcp(SOCKET s, char 730 *buffer, int length) procedure. 732 2.6.1 Initiator side 734 The buffer to be transmitted is segmented in LLCP INFORMATION 735 packets. 737 LLCPS January 2018 739 Each packet MUST be acknowledged by the Target with a RR PDU. 741 If a RNR PDU is received instead of a RR PDU then the initiator 742 sends a SYMM PDU that should be acknowledged either by a SYMM (if 743 the target is still overloaded) or by a RR PDU (if the target is 744 ready again to process INFORMATION PDUs). 746 Initiator Target 747 | | 748 Sendllcp(buffer) recvllcp() 749 | | 750 Send INFORMATION PDU -----------------> Receive INFORMATION PDU 751 NS-i++ | 752 | | 753 Receive RR <--------------------------- Send RR(NR-t) 754 | | 755 Send INFORMATION PDU -----------------> Receive INFORMATION PDU 756 NS-i++ | 757 | | 758 Receive RR <--------------------------- Send RR(NR-t) 759 | | 760 Buffer Empty | 761 | 762 Done 764 Figure 10. Sending Process, Initiator side. 766 2.6.2 Target side 768 The Target switches to the sending process, managed by the 769 sendllcp() procedure. 771 The Target MUST receive a SYMM PDU. 773 The buffer to be sent is segmented in INFORMATION PDUs. 775 Each INFORMATION PDU is sent by the Target to the Initiator and MUST 776 be acknowledged by a RR PDU. 778 If a RNR PDU is received instead of a RR PDU then the target sends a 779 SYMM PDU that should be acknowledged either by a SYMM (if the 780 initiator is still overloaded) or by a RR PDU (if the initiator is 781 ready again to process INFORMATION PDUs). 783 Upon the reception of the last RR PDU a SYMM PDU MUST be sent by the 784 Target to the Initiator. 786 LLCPS January 2018 788 Initiator Target 789 | | 790 recvllcp() sendllcp(buffer) 791 | | 792 Send SYMM --------> Receive SYMM 793 | | 794 Receive INFORMATION PDU <------- Send INFORMATION PDU 795 | NS-t++ 796 | | 797 SEND RR(NR-i) -------> Receive RR 798 | | 799 Receive INFORMATION PDU <------- Send INFORMATION PDU 800 | NS-t++ 801 | | 802 SEND RR(NR-i) -------> Receive RR 803 | | 804 | Buffer Empty 805 | | 806 Receive SYMM <------- Send SYMM 807 | | 808 Done Done 810 Figure 11. Sending Process, Target side. 812 2.7 Receiving Process 814 The Receiving process is handled by the recvllcp(SOCKET s, char 815 *buffer, int length) procedure, which manages a reception buffer. 817 2.7.1 Initiator side 819 A1) If the reception buffer is empty, the Initiator sends a SYMM 820 PDU. This PDU starts the Target receiving process. The expected PDU 821 received from the Target is either an INFORMATION PDU or a SYMM PDU 822 (notifying an ephemeral inactivity state). 824 B1) If the reception buffer stores enough data, then the size 825 requested by the recvllcp() procedure is returned. If the buffer 826 gets empty after this operation, a RR PDU is sent to the Target. The 827 PDU received from the Target is either an INFORMATION PDU or a SYMM 828 PDU. 830 B2) Else, while there is not enough data in the buffer, the 831 following loop is performed 832 - Send RR PDU 833 - Receive INFORMATION PDU 835 B2.1) at this end of this loop the size requested by the recvllcp() 836 procedure is returned. If the buffer gets empty after this 837 LLCPS January 2018 839 operation, a RR PDU is sent to the Target. The PDU received from the 840 Target is either an INFORMATION PDU or a SYMM PDU. 842 Initiator Target 843 | | 844 buffer empty sendllcp() 845 | | 846 recvllcp() ===> Send SYMM --------> Receive SYMM 847 | | 848 Receive INFORMATION PDU <------- Send INFORMATION PDU 849 | NS-t++ 850 enough data <=== | | 851 | | 852 recvllcp() ===> | | 853 enough data <=== | | 854 buffer empty | 855 | | 856 Send RR(NR-i) -------> Receive RR 857 | | 858 Receive INFORMATION PDU <------- Send INFORMATION PDU 859 | NS-t++ 860 | | 861 recvllcp() ===> Send RR(NR-i) -------> Receive RR 862 | | 863 Receive INFORMATION PDU <------- Send INFORMATION PDU 864 | NS-t++ 865 enough data <=== | | 866 | | 867 recvllcp() ===> | | 868 Send RR(NR-i) -------> Receive RR 869 | | 870 Receive INFORMATION PDU <------- Send INFORMATION PDU 871 | NS-t++ 872 | | 873 ===> Send RR(NR-i) -------> Receive RR 874 | | 875 Receive INFORMATION PDU <------- Send INFORMATION PDU 876 | NS-t++ 877 enough data <=== | | 878 buffer empty | 879 | | 880 Send RR(NR-i) -------> Receive RR 881 | | 882 | buffer empty 883 | | 884 Receive SYMM <------- Send SYMM 885 | | 886 Done Done 888 Figure 12. Receiving Process, Initiator side. 890 LLCPS January 2018 892 2.7.2 Target side 894 A1) If the reception buffer stores enough data, then the size 895 requested by the recvllcp() procedure is returned. 897 B1) Else, while there is not enough data in the buffer, the 898 following loop is performed 899 - Receive INFORMATION PDU 900 - Send RR PDU 902 Initiator Target 903 | | 904 Sendllcp(buffer) buffer empty 905 | | 906 | | <=== recvllcp() 907 | | 908 Send INFORMATION PDU ----> Receive INFORMATION PDU 909 NS-i++ | 910 | | 911 Receive RR <------------ Send RR(NR-t) 912 | | 913 | | ===> enough data 914 | | 915 | | <=== recvllcp() 916 | | ===> enough data 917 | | 918 | buffer empty 919 | | 920 | | <=== recvllcp() 921 | | 922 Send INFORMATION PDU --> Receive INFORMATION PDU 923 NS-i++ | 924 | | 925 Receive RR <------------ Send RR(NR-t) 926 | | 927 Send INFORMATION PDU --> Receive INFORMATION PDU 928 NS-i++ | 929 | | 930 Receive RR <------------ Send RR(NR-t) 931 | | 932 buffer empty | ===> enough data 933 | buffer empty 934 Done | 935 Done 937 Figure 13. Receiving Process, Initiator side. 939 LLCPS January 2018 941 3 TLS support over LLCP, Connectionless Transport 943 In NFC P2P mode the Initiator detects a Target and afterwards starts 944 and manages a data exchange session; it may optionally feed the 945 Target device. 947 The Initiator has consequently a longer useful life than the Target; 948 it is a legitimate place to host TLS server in a permanent way. 950 However the TLS server MAY be hosted on the Initiator or on the 951 Target side. 953 Each entity manages five exclusive processes 955 - The Connection Process (CP) 956 - The Disconnection Process (DP) 957 - The Sending Process (SP) 958 - The Receiving Process (RP) 959 - The Inactivity Process (IP) 961 The Inactivity Process MAY be started (see figure 14) each time a 962 receiving or sending buffer is empty; in this case it is assumed 963 that the computing time or the delay required before the next 964 input/output operation is greater than the LLCP timeout (LTO). 966 LLCPS January 2018 968 Initiator Target 969 | | 970 Connection Process Connection Process 971 | | 972 | Sending Process 973 | | 974 Send SYMM ---------------> Receive SYMM 975 Receive UI <---------------- Send UI 976 | | 977 Receiving Process | 978 | | 979 Send SYMM -----------------> Receive SYMM 980 Receive UI <---------------- Send UI 981 | | 982 | Inactivity Process 983 | | 984 Send SYMM ----------------> Receive SYMM 985 Receive SYMM <---------------- Send SYMM 986 | | 987 Inactivity Process Receiving Process 988 | | 989 Send SYMM -----------------> Receive SYMM 990 Receive SYMM <---------------- Send SYMM 991 | | 992 Sending Process | 993 Send UI ------------------> Receive UI 994 Receive SYMM <----------------- Send SYMM 995 | | 996 Receiving Process Inactivity Process 997 | | 998 Send SYMM -----------------> Receive SYMM 999 Receive SYMM <---------------- Send SYMM 1000 | | 1001 | Sending Process 1002 Send SYMM ------------> Receiving SYMM 1003 Receive UI <------------- Send UI 1004 | | 1005 | Inactivity Process 1006 Send SYMM -----------------> Receive SYMM 1007 Receive SYMM <---------------- Send SYMM 1008 | | 1009 | | 1010 Disconnection Process | 1011 | | 1012 Send DM --------------> Receive DM 1013 Receive SYMM or DM <------------ Send SYMM or DM 1014 | | 1016 Figure 14. Overview of Process Operations, connectionless mode 1017 LLCPS January 2018 1019 3.1 Peer To Peer Link Establishment 1021 As described in section 1, the Initiator periodically probes the 1022 presence of a Target. At the end of the "Protocol Activation and 1023 Parameters Selection" phase, ATR-REQ and ATR-RESP messages have been 1024 exchanged, and LLCP services are available on both Initiator and 1025 Target nodes, including in particular the Data-Request-i/t and Data- 1026 Indication-i/t primitives. 1028 Due to the ephemeral intrinsic nature of an NFC connection, the P2P 1029 session may be broken at any time, which implies transmission or 1030 reception errors notified by the MAC primitives. 1032 As a consequence an LLCP session is assumed to be released at the 1033 first MAC error. 1035 Once a NFC P2P link is established, TLS server and client software 1036 entities are activated. Procedures such as: 1038 - SOCKET acceptllcp(char TLS-SAP), and 1039 - SOCKET connectllcp(char TLS-SAP) 1041 MAY be used respectively on Initiator and Target sides, in order to 1042 get a SOCKET. This object supports additional facilities, typically 1043 the following procedures: 1045 - int sendllcp(SOCKET s, char *buffer, int length) 1046 - int recvllcp(SOCKET s, char *buffer, int length) 1047 - int closellcp(SOCKET s) 1049 which are used for the LLCP session management. 1051 LLCPS January 2018 1053 3.2 Inactivity Process 1055 When the LLCP layer detects an inactivity period greater that a 1056 given timeout value (see figure 15), it generates a SYMM PDU. 1057 Therefore each time a LLCP layer is waiting for a non SYMM PDU, and 1058 receives a SYMM PDU, it MUST acknowledge it by sending a SYMM PDU. A 1059 maximum number (SYMM-Ct-i/t) of echoed SYMM PDU SHOULD be defined. 1061 Upon the reception of an UI PDU, the packet is stored in the 1062 reception buffer. 1064 The Inactivity Process (IP) MAY start between the Receiving Process 1065 (RP) and the Sending Process (SP). 1067 Initiator Target 1068 | | 1069 +------> LLCP inactivity + <-------------+ 1070 | | | | 1071 | +----------+-----------+ +------------+-----------+ | 1072 | + Inactivity Timeout + + Waiting for a LLCP PDU + | 1073 | +----------+-----------+ +------------+-----------+ | 1074 | | | | 1075 | Send SYMM PDU ----> Reception of a PDU | 1076 | | | | | 1077 | | |SYMM or UI |Other | 1078 | Reception of a PDU <---- |Send SYMM PDU |PDU | 1079 | | | | |Excepted| 1080 | SYMM or UI| |Other PDU SYMM-Ct-t++ |UI | 1081 | SYMM-Ct-i++| |Excepted UI | | | 1082 +-------------+ +--+ +------------|--------+ 1083 | | 1084 End Of LLCP Inactivity Send a LLCP PDU 1086 Figure 15. Inactivity Process 1088 3.3 Connection Process, the Initiator is Server, the Target is Client 1090 3.3.1 Initiator side 1092 The Initiator MUST transmit a SYMM PDU. 1094 If the Initiator receives a SYMM then it sends a SYMM. 1096 If the Initiator receives an UI PDU, with the DSAP set to a well- 1097 known value that identifies the TLS service, then the service data 1098 unit transported by the UI is stored in the reception buffer. 1100 If the DSAP value is incorrect the Initiator transmits a DM PDU with 1101 a reason code. 1103 LLCPS January 2018 1105 3.3.2 Target side 1107 The Target allocates an ephemeral SSAP ranging between 16 and 31, 1108 and sends a SYMM. 1110 The DSAP of UI PDU will use the allocated SSAP, and DSAP set to a 1111 well-known value that identifies the TLS service. 1113 3.3.3 Connection choreography 1115 Initiator Target 1116 | | 1117 socket= acceptllcp(TLS-SAP) socket=connectllcp(TLS-SAP) 1118 | | 1119 | DSAP=well-known value 1120 | Allocate Ephemeral SSAP 1121 | | 1122 | Done 1123 | | 1124 | sendllcp() 1125 | | 1126 Send SYMM ------------------> Receive SYMM 1127 | | 1128 Receive UI <------------------ Send UI 1129 Check DSAP | 1130 | | 1131 Done 1133 Figure 15. Connection Choreography 1135 3.4 Connection Process, the Initiator is Client, the Target is Server 1137 3.4.1 Initiator side 1139 The initiator allocates an ephemeral SSAP ranging between 16 and 31, 1140 and sends a SYMM. 1142 The DSAP of UI PDU will use the allocated SSAP, and DSAP set to a 1143 well-known value that identifies the TLS service. 1145 3.4.2 Target side 1147 If target receives a SYMM, then it sends A SYMM. 1149 If the Target receives an UI PDU, with the DSAP set to a well-known 1150 value that identifies the TLS service, then the service data unit 1151 transported by the UI is stored in the reception buffer. 1153 Upon success the Target sends a SYMM. 1155 LLCPS January 2018 1157 If the DSAP value is incorrect the Initiator transmits a DM PDU with 1158 a reason code. 1160 3.4.3 Connection choreography 1162 Initiator Target 1163 | | 1164 socket= connectllcp(TLS-SAP) socket= acceptllcp(TLS-SAP) 1165 | | 1166 DSAP=well-known value | 1167 Allocate Ephemeral SSAP | 1168 | | 1169 Done | 1170 | | 1171 Sendllcp() | 1172 | | 1173 Send UI -------------------> Receive UI 1174 receive SYMM <------------------ Send SYMM 1175 | | 1176 Done Done 1178 Figure 16. Connection Choreography 1180 3.5 Disconnection Process 1182 Due to the ephemeral nature of P2P NFC session, the disconnection 1183 process MAY be unavailable. Nerveless it SHOULD be used for a 1184 graceful closing of a TLS session. The Disconnection Process is 1185 initiated by the Initiator or the Target. 1187 3.5.1 Disconnection initiated by the Initiator 1189 The Initiator MUST send a DM PDU 1191 The Target receives the DM PDU. 1193 The Target sends a SYMM or a DM PDU. 1195 3.5.2 Disconnection initiated by the Target 1197 If the Target receives a DM PDU, then it sends the DM or the SYMM 1198 PDU. 1200 Else the Target sends the DM PDU. 1202 LLCPS January 2018 1204 3.5.3 Disconnection choreography 1206 Initiator Target 1207 | | 1208 closellcp(socket) | 1209 | | 1210 Send DM -----------------> Receive DM 1211 | | 1212 Receive SYMM or DM <---------------- Send SYMM or DM 1213 | | 1214 Done Done 1216 Figure 17. Disconnection initiated by the Initiator 1218 Initiator Target 1219 | | 1220 | closellcp(socket) 1221 | | 1222 Send SYMM -------------> Receive LLCP PDU 1223 | | 1224 Receive DM <------------ Send DM 1225 | | 1226 Done Done 1228 Figure 18. Disconnection initiated by the Target 1230 3.6 Sending Process 1232 The data transmission is managed by the 1233 sendllcp(SOCKET s, char *buffer, int length) 1234 procedure. 1236 3.6.1 Initiator side 1238 The buffer to be transmitted is segmented in LLCP UI packets. 1240 Initiator Target 1241 | | 1242 Sendllcp(buffer) recvllcp() 1243 | | 1244 Send UI PDU -----------------> Receive UI PDU 1245 Receive SYMM <----------------- Send SYMM 1246 | | 1247 Send UI PDU -----------------> Receive UI PDU 1248 Receive SYMM <----------------- Send SYMM 1249 | | 1250 Buffer Empty | 1251 | 1252 Done 1254 Figure 19. Sending Process, Initiator side. 1256 LLCPS January 2018 1258 The following loop is performed 1260 - The Initiator sends an UI PDU 1261 - The initiator receive a SYMM PDU 1263 3.6.2 Target side 1265 The Target switches to the sending process, managed by the 1266 sendllcp() procedure. 1268 The Target MUST receive a SYMM PDU. 1270 The buffer to be sent is segmented in UI PDUs. 1272 The following loop is performed 1274 - The Target sends an UI PDU 1275 - The Target receives a SYMM PDU 1277 When the buffer is empty a last SYMM is sent. 1279 Initiator Target 1280 | | 1281 recvllcp() sendllcp(buffer) 1282 | | 1283 Send SYMM --------> Receive SYMM 1284 | | 1285 Receive UI <------- Send UI 1286 | | 1287 Send SYMM --------> Receive SYMM 1288 | | 1289 Receive UI <------- Send UI 1290 | Buffer Empty 1291 | | 1292 Receive SYMM <------- Send SYMM 1293 | | 1294 | Done 1296 Figure 20. Sending Process, Target side. 1298 LLCPS January 2018 1300 3.7 Receiving Process 1302 The Receiving process is handled by the 1303 recvllcp(SOCKET s, char *buffer, int length) 1304 procedure, which manages a reception buffer. 1306 3.7.1 Initiator side 1308 A1) If the reception buffer is empty, the Initiator sends a SYMM 1309 PDU. This PDU starts the Target receiving process. The expected PDU 1310 received from the Target is either an UI PDU or a SYMM PDU 1311 (notifying an ephemeral inactivity state). 1313 B1) If the reception buffer stores enough data, then the size 1314 requested by the recvllcp() procedure is returned. If the buffer 1315 gets empty after this operation, the SYMM PDU SHOULD be sent to the 1316 Target. The PDU received from the Target is either an UI PDU or a 1317 SYMM PDU. 1319 B2) Else, while there is not enough data in the buffer, the 1320 following loop is performed 1321 - Send SYMM 1322 - Receive UI PDU 1324 B2.1) at this end of this loop the size requested by the recvllcp() 1325 procedure is returned. If the buffer gets empty after this 1326 operation, the SYMM PDU SHOULD be sent to the Target. The PDU 1327 received from the Target is either an UI PDU or a SYMM PDU. 1329 In B1 and B2.1 a SYMM PDU SHOULD be sent when the reception buffer 1330 gets empty. This rule avoids un-needed transition to the IP process. 1331 It is a "double checking" of the empty buffer event. 1333 LLCPS January 2018 1335 Initiator Target 1336 | | 1337 buffer empty sendllcp() 1338 | | 1339 recvllcp() ===> Send SYMM --------> Receive SYMM 1340 | | 1341 Receive UI <------- Send UI PDU 1342 enough data <=== | | 1343 | | 1344 recvllcp() ===> | | 1345 enough data <=== | | 1346 buffer empty | 1347 | | 1348 Send SYMM --------> Receive SYMM 1349 Receive UI <-------- Send UI 1350 | | 1351 Send SYMM -------> Receive SYMM 1352 | | 1353 Receive UI <------- Send UI PDU 1354 | | 1355 recvllcp() ===> | | 1356 enough data <=== | | 1357 | | 1358 recvllcp() ===> | | 1359 Send SYMM -------> Receive SYMM 1360 | | 1361 Receive UI <------- Send UI PDU 1362 | | 1363 Send SYMM -------> Receive SYMM 1364 | | 1365 Receive UI <------- Send UI PDU 1366 enough data <=== | | 1367 buffer empty Done 1368 | | 1369 | Inactivity Process 1370 | | 1371 Send SYMM --------> Receive SYMM 1372 Receive SYMM <-------- Send SYMM 1373 | | 1374 Done Done 1376 Figure 21. Receiving Process, Initiator side. 1378 LLCPS January 2018 1380 3.7.2 Target side 1382 A1) If the reception buffer stores enough data, then the size 1383 requested by the recvllcp() procedure is returned. 1385 B1) Else, while there is not enough data in the buffer, the 1386 following loop is performed 1387 - Receive UI PDU 1388 - Send SYMM PDU 1390 Initiator Target 1391 | | 1392 Sendllcp(buffer) buffer empty 1393 | | 1394 | | <=== recvllcp() 1395 | | 1396 Send UI PDU -----------> Receive UI PDU 1397 | | 1398 Receive SYMM <------------ Send SYMM 1399 | | 1400 | | ===> enough data 1401 | | 1402 | | <=== recvllcp() 1403 | | ===> enough data 1404 | | 1405 | buffer empty 1406 | | 1407 | | <=== recvllcp() 1408 | | 1409 Send UI PDU ----------> Receive UI PDU 1410 | | 1411 Receive SYMM <----------- Send SYMM 1412 | | 1413 Send UI -----------> Receive UI PDU 1414 | | 1415 Receive SYMM <------------ Send SYMM 1416 | | 1417 Done | ===> enough data 1418 | buffer empty 1419 | | 1420 | | 1421 Done 1423 Figure 22. Receiving Process, Target side. 1425 LLCPS January 2018 1427 4 Example of LLCPS session, connected mode 1429 4.1 Protocol Activation and Parameters Selection 1431 4.1.1 Initiator ATR-REQ 1433 Raw-data: 1434 5C A9 BE E1 C0 35 A0 BF 16 0F 00 00 00 02 46 66 1435 6D 01 01 10 03 02 00 01 04 01 01 10 64 1437 NFCID3i= 5C A9 BE E1 C0 35 A0 BF 16 0F 1438 DIDi (Initiator ID) = 00 1439 BSi= 00 1440 BRi= 00 1441 PPi= 02, 64 bytes of Transport Data, Gt bytes available 1442 Magic Bytes: 46666d 1443 Option: Version, Major=1, Minor=0 1444 Option: WKS: Well-Known Service List 0x0001 1445 Option: LTO: Link TimeOut 0x64 (1000 ms) 1447 4.1.2 Target ATR-RESP 1449 Raw-Data: 1450 AA 99 88 77 66 55 44 33 22 11 00 00 00 09 03 46 1451 66 6D 01 01 10 03 02 00 01 04 01 64 1453 NFCID3t= AA 99 88 77 66 55 44 33 22 11 1454 DIDt (Target ID)= 00 1455 BSt= 00 1456 BRt= 00 1457 TO= 09, WT= 6363 ms 1458 PPt= 03, 64 bytes of Transport Data, NAD available, Gt bytes 1459 available 1460 Magic Bytes: 46666d 1461 Option: Version, Major=1, Minor=0 1462 Option: WKS: Well-Known Service List 0x0001 1463 Option: LTO: Link TimeOut 0x64 (1000 ms) 1465 4.2 LLCP connection 1467 Initiator: Sending SYMM, ssap=0 dsap=0 1468 Tx-i: 00 00 1469 Target: Sending CONNECT, ssap=27 dsap=1, option=SN("com.ietf.tls") 1470 Rx_i: 05 1B 06 0C 63 6F 6D 2E 69 65 74 66 2E 74 6C 73 1471 Initiator: Sending ConnectionComplete, ssap=16 dsap=27 1472 Tx-i: 6D 90 1473 Target: Sending SYMM, ssap=0 dsap=0 1474 Rx-i: 00 00 1475 LLCPS January 2018 1477 4.3 Target: sending Client Hello 1479 RecvLLCP Initiator: request size=5, buffer empty, sending SYMM 1480 Initiator: Sending SYMM, ssap=0 dsap=0 1481 Tx-i: 00 00 1483 SendLLCP Target: request size=82 bytes, Waiting for SYMM 1484 Target: Receiving SYMM, ssap=0 dsap=0 1485 Target: Sending INFORMATION, ssap=27 dsap=16 Nr=0, Ns=0 1486 Rx-i: 43 1B 00 16 03 01 00 4D 01 00 00 49 03 01 50 1A 1487 A9 6B 82 55 1C B5 AD FF BC 87 21 66 5F B5 98 41 1488 9E 17 33 39 45 F9 78 86 46 D6 F6 75 51 10 20 E7 1489 0A 41 FE 8C F9 A0 38 D3 28 72 E8 04 7E C2 37 22 1490 05 13 24 AA DE 2F 6B 67 4C 19 CE A5 7D A0 86 00 1491 02 00 04 01 00 1493 RecvLLCP_Initiator: request size=5 bytes, buffer=82 bytes 1494 RecvLLCP_Initiator: request size=77 bytes, buffer=77 bytes 1495 RecvLLCP_Initiator: buffer empty, sending RR(1), ssap=16 dsap=27 1496 Tx-i: 6F 50 01 1498 SendLLCP_Target: Receiving RR(1), ssap=16 dsap=27 1499 SendLLCP_Target: empty buffer, Done, Sending SYMM 1500 Target: Sending SYMM, ssap=0 dsap=0 1502 Initiator: Receiving SYMM ssap=0 dsap=0 1503 Rx-i: 00 00 1505 4.4 Inactivity Process 1507 Initiator: Sending SYMM, ssap=0 dsap=0 1508 Tx-i: 00 00 1510 RecvLLCP Target: request size=5 bytes, buffer empty 1511 Target: Receiving SYMM, ssap=0 dsap=0 1512 Target: Sending SYMM, ssap=0 dsap=0 1514 Initiator: Receiving SYMM, ssap=0 dsap=0 1515 Rx-i: 00 00 1517 4.5 Server: sending Server Hello 1519 SendLLCP_Initiator: request size=122 bytes 1520 Initiator: Sending INFORMATION, ssap=16 dsap=27 Nr=1 Ns=0 1521 Tx-i: 6F 10 01 16 03 01 00 4A 02 00 00 46 03 01 50 1A 1522 A9 6B 6C 0E 31 E1 F3 0E CD 18 E7 6F 81 BF 5F 3C 1523 FD DE 00 4C A4 12 AE DC DF E4 FF 82 09 5E 20 E7 1524 0A 41 FE 8C F9 A0 38 D3 28 72 E8 04 7E C2 37 22 1525 05 13 24 AA DE 2F 6B 67 4C 19 CE A5 7D A0 86 00 1526 04 00 14 03 01 00 01 01 16 03 01 00 20 83 18 D1 1527 LLCPS January 2018 1529 E3 BC 3A 94 26 91 3D FC F3 8E 01 46 5E 52 8E 67 1530 A2 66 FC 5F D5 89 78 59 66 14 BA D3 B0 1532 RecvLLCP_Target: Receiving INFORMATION, ssap=16 dsap=27 Nr=1 Ns=0 1533 RecvLLCP_Target: sending RR(1), ssap=27 dsap=16 1534 RecvLLCP_Target: request size=74 bytes 1535 RecvLLCP_Target: request size=5 bytes 1536 RecvLLCP_Target: request size=1 byte 1538 SendLLCP Initiator: Receiving RR(1), ssap=27 dsap=16 1539 Rx-i: 43 5B 01 1540 SendLLCP_Initiator: buffer empty, Done 1542 RecvLLCP_Target: request size=5 bytes 1543 RecvLLCP_Target: request size=32 bytes, Done, empty buffer 1545 4.6 LLCP Inactivity Process 1547 RecvLLCP_Initiator: request size=5, empty buffer, sending SYMM 1548 Initiator: Sending SYMM, ssap=0 dsap=0 1549 Tx-i: 00 00 1551 Target: Receiving SYMM, ssap=0 dsap=0 1552 Target: Sending SYMM, ssap=0 dsap=0 1554 Initiator: Receiving SYMM ssap=0 dsap=0 1555 Rx-i: 00 00 1557 4.7 Client: sending Client Finished 1559 Initiator: Receiving SYMM ssap=0 dsap=0 1560 Tx-i: 00 00 1562 SendLLCP_Target: request size=43 bytes, Waiting for SYMM 1563 Target: Receiving SYMM, ssap=0 dsap=0 1564 Target: Sending INFORMATION, ssap=27 dsap=16 Nr=1, Ns=1 1565 Rx-i: 43 1B 11 14 03 01 00 01 01 16 03 01 00 20 57 DD 1566 DE 29 9E E4 EF DD C5 18 87 50 C6 C7 B9 56 AD FA 1567 EF 65 B2 24 48 04 2E FE 7D BD 97 E1 F3 3A 1569 Initiator: Receiving INFORMATION, ssap=27 dsap=16 Nr=1, Ns=1 1570 RecvLLCP_Initiator: request size= 5 bytes, buffer=43 bytes 1571 RecvLLCP_Initiator: request size= 1 bytes, buffer=38 bytes 1572 RecvLLCP_Initiator: request size= 5 bytes, buffer=37 bytes 1573 RecvLLCP_Initiator: request size=32 bytes, buffer=32 bytes 1574 RecvLLCP_Initiator: empty buffer, sending RR(2) 1575 Initiator: Sending RR(2), ssap=16 dsap=27 1576 Tx-i: 6F 50 02 1578 Target: Receiving RR(2), ssap=16 dsap=27 Nr=2 1579 LLCPS January 2018 1581 SendLLC_Target: empty buffer, Done, sending SYMM 1582 Target: Sending SYMM, ssap=0 dsap=0 1584 Initiator: Receiving SYMM ssap=0 dsap=0 1585 Rx-i: 00 00 1587 4.8 Exchanging Data 1589 4.8.1 Sending data from client to server 1591 RecvLLCP_Initiator: request size=5 bytes, empty buffer, sending SYMM 1592 Initiator: Sending SYMM, ssap=0 dsap=0 1593 Tx-i: 00 00 1595 Target: Receiving SYMM, ssap=0 dsap=0 1596 SendLLCP_Target: sending 27 bytes 1597 Target: Sending INFORMATION, ssap=27 dsap=16 Nr=1, Ns=2 1599 Initiator: Receiving INFORMATION, ssap=27 dsap=16 Nr=1, Ns=2 1600 Rx-i: 43 1B 21 17 03 01 00 16 C2 D5 18 CB 0D AB 44 E5 1601 0F 25 DB 83 6D 26 B7 74 E7 90 EF 33 8C FE 1602 RecvLLCP_Initiator: request size= 5 bytes, buffer=27 bytes 1603 RecvLLCP_Initiator: request size=22 bytes, buffer=22 bytes 1604 Initiator: Sending RR(3), ssap=16 dsap=27 1605 Tx-i: 6F 50 03 1607 Target: Receiving RR(3), ssap=16 dsap=27 1608 SendLLC_Target: empty buffer, Done, sending SYMM 1609 Target: Sending SYMM, ssap=0 dsap=0 1611 Initiator: Receiving SYMM ssap=0 dsap=0 1612 Rx-i: 00 00 1614 4.8.2 Sending data from server to client 1616 SendLLCP Initiator: request size=27 bytes 1617 Initiator: Sending INFORMATION, ssap=16 dsap=27 Nr=3 Ns=1 1618 Tx-i: 6F 10 13 17 03 01 00 16 DC 82 FE B9 EA 1C 63 5C 1619 AC 8C FE C9 A2 4F 8A FD 54 EE 18 F5 DB 30 1621 RecvLLCP_Target: request size= 5 bytes 1622 Target: Receiving INFORMATION, ssap=16 dsap=27 Nr=3 Ns=1 1623 RecvLLCP_Target: sending RR(2) 1624 Target: Sending RR(2), ssap=27 dsap=16 1625 RecvLLCP_Target: request size=22 bytes, buffer=22 bytes, Done 1627 Initiator: Receiving RR(2), ssap=27 dsap=16 1628 Rx-i: 43 5B 02 1629 SendLLCP Initiator: empty buffer, Done 1630 LLCPS January 2018 1632 4.9 Closing TLS session, initiated by the Initiator 1634 Initiator: Sending DISC, ssap=16 dsap=27 1635 Tx-i: 6D 50 1637 Target: Receiving DISC, ssap=16 dsap=27 1638 Target: Sending DM, ssap=27 dsap=16 1640 Initiator: Receiving DM, ssap=27 dsap=16 1641 Rx-i: 41 DB 00 1643 5 Example of LLCPS session, Connectionless mode 1645 5.1 Protocol Activation and Parameters Selection 1647 5.1.1 Initiator ATR-REQ 1649 Raw-data: 1650 5C A9 BE E1 C0 35 A0 BF 16 0F 00 00 00 02 46 66 1651 6D 01 01 10 03 02 00 01 04 01 01 10 64 1653 NFCID3i= 5C A9 BE E1 C0 35 A0 BF 16 0F 1654 DIDi (Initiator ID) = 00 1655 BSi= 00 1656 BRi= 00 1657 PPi= 02, 64 bytes of Transport Data, Gt bytes available 1658 Magic Bytes: 46666d 1659 Option: Version, Major=1, Minor=0 1660 Option: WKS: Well-Known Service List 0x0001 1661 Option: LTO: Link TimeOut 0x64 (1000 ms) 1663 5.1.2 Target ATR-RESP 1665 Raw-Data: 1666 AA 99 88 77 66 55 44 33 22 11 00 00 00 09 03 46 1667 66 6D 01 01 10 03 02 00 01 04 01 64 1669 NFCID3t= AA 99 88 77 66 55 44 33 22 11 1670 DIDt (Target ID)= 00 1671 BSt= 00 1672 BRt= 00 1673 TO= 09, WT= 6363 ms 1674 PPt= 03, 64 bytes of Transport Data, NAD available, Gt bytes 1675 available 1676 Magic Bytes: 46666d 1677 Option: Version, Major=1, Minor=0 1678 Option: WKS: Well-Known Service List 0x0001 1679 Option: LTO: Link TimeOut 0x64 (1000 ms) 1680 LLCPS January 2018 1682 5.2 LLCP connection 1684 Initiator: Sending SYMM, ssap=0 dsap=0 1685 Tx-i: 00 00 1687 Target: Setting DSAP to 13 (well known-value), setting ephemeral 1688 SSAP to 27 1690 5.3 Client Hello 1692 Target: Receiving SYMM, ssap=0 dsap=0 1693 Target: Sending UI, dsap=13 ssap=27, 82 bytes 1695 Initiator: Receiving UI, ssap=27 dsap=13 1696 Rx-i: 34 DB 16 03 01 00 4D 01 00 00 49 03 01 51 09 2E 1697 3A CC 72 28 FE F5 D3 6F A8 D9 E7 55 67 6C 3B C3 1698 7C 6C AF 18 1A 7F C6 81 1A 9D 0F 3D F8 20 04 E2 1699 26 36 24 92 33 68 48 C7 34 A4 44 E3 70 8C 6C 11 1700 44 53 54 20 B1 A9 3D 47 A8 3F E5 C5 D5 D2 00 02 1701 00 04 01 00 90 00 1703 RecvLLC Initiator: request size=5 buffer size=82 1704 RecvLLC Initiator: request size=77 buffer size=77 1705 RecvLLC Initiator: buffer empty 1707 Initiator: Sending SYMM, ssap=0 dsap=0 1708 Tx-i: 00 00 1710 Target: Receiving SYMM, ssap=0 dsap=0 1711 Target: Sending SYMM, ssap=0,dsap=0 1713 Rx-i: 00 00 1715 5.4 Server Hello 1717 SendLLC Initiator: request size=122 1718 Initiator: Sending UI, ssap=13 dsap=27 1720 Tx-i: 6C CD 16 03 01 00 4A 02 00 00 46 03 01 51 09 2E 1721 3A 23 03 7D 28 AF D1 71 B4 0F 60 ED 3D A0 86 4B 1722 67 36 A8 80 AB 34 78 21 63 1B D8 F5 81 20 04 E2 1723 26 36 24 92 33 68 48 C7 34 A4 44 E3 70 8C 6C 11 1724 44 53 54 20 B1 A9 3D 47 A8 3F E5 C5 D5 D2 00 04 1725 00 14 03 01 00 01 01 16 03 01 00 20 B9 0C 3F E8 1726 C8 48 F3 8B 1A 1C 59 01 6C C9 A0 7F 33 FB E9 A3 1727 1E 9E 25 B8 FA AE FE 77 06 51 3D E4 1729 Target: Receiving UI, ssap=13 dsap=27, 122 bytes 1731 RecvLLC Target: request size= 5, buffer size= 122 1732 RecvLLC Target: request size=74, buffer size= 117 1733 LLCPS January 2018 1735 RecvLLC Target: request size= 5, buffer size= 43 1736 RecvLLC Target: request size= 1, buffer size= 42 1737 RecvLLC Target: request size= 5, buffer size= 37 1738 RecvLLC Target: request size=32, buffer size= 32 1739 RecvLLC Target: empty buffer 1741 Target: Sending SYMM, ssap=0 dsap=0 1743 Initiator: Receiving SYMM, ssap=0 dsap=0 1744 Rx-i: 00 00 1746 5.5 Client Finished 1748 Initiator: Sending SYMM, ssap=0 dsap=0 1749 Tx-i: 00 00 1751 Target: Receiving SYMM, ssap=0 dsap=0 1753 SendLLC Target: sending 43 bytes 1754 Target: Sending UI, ssap=27 dsap=13, 43 bytes 1756 Initiator: Receiving UI, ssap=27 dsap=13, 43 bytes 1758 Rx-i: 34 DB 14 03 01 00 01 01 16 03 01 00 20 7E 92 D1 1759 D1 78 C4 39 2D 8D 11 9A DF 0F 0B E5 7C 33 BA DC 1760 3D B0 33 CD 5E 27 BE A4 6C 62 78 F3 D8 1762 RecvLLC Initiator: request size=5 buffer size=43 1763 RecvLLC Initiator: request_size=1 buffer size=38 1764 RecvLLC Initiator: request_size=5 buffer_size=37 1765 RecvLLC Initiator: request_size=32 buffer size=32 1766 RecvLLC_Initiator: buffer empty 1768 Initiator: Sending SYMM, ssap=0 dsap=0 1769 Tx-i: 00 00 1771 Target: Receiving SYMM, ssap=0 dsap=0 1772 Target: Sending SYMM, ssap=0,dsap=0 1773 Rx-i: 00 00 1775 5.6 Exchanging Data 1777 5.6.1 Sending data from client to server 1779 Initiator: Sending SYMM, ssap=0 dsap=0 1780 Tx-i: 00 00 1782 Target: Receiving SYMM, ssap=0 dsap=0 1783 Target: Sending UI, ssap=27 dsap=13, 27 bytes 1784 LLCPS January 2018 1786 Rx-i: 34 DB 17 03 01 00 16 EA 91 72 8A DA 5A DD F0 C7 1787 6A E0 82 15 B4 8F 5E 72 F6 BE 64 9D 0E 1789 Initiator: Receiving UI, ssap=27 dsap=13, 27 bytes 1791 SendLLC Initiator: request size= 5, buffer size=32 1792 SendLLC Initiator: request size=27, buffer size=27 1793 SendLLC Initiator: buffer empty 1795 Initiator: Sending SYMM, ssap=0 dsap=0 1796 Tx-i: 00 00 1798 Target: Sending SYMM, ssap=0,dsap=0 1799 Initiator: Receiving SYMM, ssap=0 dsap=0 1801 Rx-i: 00 00 1803 5.6.2 Sending data from server to client 1805 Initiator: Sending UI, ssap=13 dsap=27, 27 bytes 1807 Tx-i: 6C CD 17 03 01 00 16 93 48 F4 7F 67 F8 6E A1 94 1808 15 BB AF D1 BD CA 2D AE 48 0B A6 9B 9D 1810 Target: Receiving UI, ssap=13 dsap=27, 27 bytes 1811 Target: Sending SYMM, ssap=0,dsap=0 1813 RecvLLC Target: request size= 5, buffer size=32 1814 RecvLLC Target: request size=27, buffer size=27 1815 RecvLLC Target: buffer empty 1817 Initiator: Receiving SYMM, ssap=0 dsap=0 1818 Rx-i: 00 00 1820 5.7 End of Session 1822 Initiator: Sending DM, ssap=0 dsap=0 1823 Target: Receiving DM, ssap=0 dsap=0 1824 Target: Sending SYMM, ssap=0 dsap=0 1825 Initiator: Receiving SYMM, ssap=0 dsap=0 1826 LLCPS January 2018 1828 6 Security Considerations 1830 To be done. 1832 7 IANA Considerations 1834 8 References 1836 8.1 Normative References 1838 [TLS 1.0] Dierks, T., C. Allen, "The TLS Protocol Version 1.0", RFC 1839 2246, January 1999 1841 [TLS 1.1] Dierks, T., Rescorla, E., "The Transport Layer Security 1842 (TLS) Protocol Version 1.1", RFC 4346, April 2006 1844 [TLS 1.2] Dierks, T., Rescorla, E., "The Transport Layer Security 1845 (TLS) Protocol Version 1.1", draft-ietf-tls-rfc4346-bis-10.txt, 1846 March 2008 1848 [RFC 5216] B. Aboba, D. Simon, R. Hurst, "EAP TLS Authentication 1849 Protocol" RFC 5216, March 2008. 1851 [ECMA340] "Near Field Communication Interface and Protocol (NFCIP- 1852 1)", Standard ECMA-340, December 2004 1854 [ISO/IEC 18092] "Information technology - Telecommunications and 1855 information exchange between systems - Near Field Communication - 1856 Interface and Protocol (NFCIP-1)", April 2004 1858 [LLCP] "Logical Link Control Protocol", Technical Specification, NFC 1859 ForumTM, LLCP 1.1, June 2011 1861 [SNEP] "Simple NDEF Exchange Protocol", Technical Specification, NFC 1862 ForumTM, SNEP 1.0, August 2011 1864 [NDEF] "NFC Data Exchange Format (NDEF)", Technical Specification 1865 NFC ForumTM, NDEF 1.0, July 2006. 1867 [ISO7816] ISO 7816, "Cards Identification - Integrated Circuit Cards 1868 with Contacts", The International Organization for Standardization 1869 (ISO) 1871 [IEEE 802.2] IEEE Std 802.2, "IEEE Standard for Information 1872 technology Telecommunications and information exchange between 1873 systems Local and metropolitan area networks, Specific requirements, 1874 Part 2: Logical Link Control", 1998 1875 LLCPS January 2018 1877 8.2 Informative References 1879 [NPP} "Android NDEF Push Protocol Specification Version 1", February 1880 2011 1882 9 Authors' Addresses 1884 Pascal Urien 1885 Telecom ParisTech 1886 23 avenue d' Italie 1887 75013 Paris Phone: NA 1888 France Email: Pascal.Urien@telecom-paristech.fr