idnits 2.17.1 draft-urien-tls-llcp-00.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 -- The document date (August 14, 2012) is 4271 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'NPP' is mentioned on line 135, 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 August 14, 2012 7 Expires: February 2013 9 LLCPS 10 draft-urien-tls-llcp-00.txt 12 Abstract 14 This document describes the implementation, named LLCPS, of the TLS 15 protocol over the NFC (Near Field Communication) LLCP layer. The NFC 16 peer to peer (P2P) protocol may be used by any application that 17 needs communication between two devices at very small distances (a 18 few centimeters). LLCPS enforces a strong security in NFC P2P 19 exchanges, and may be deployed for many services, in the Internet Of 20 Things ecosystem, such as access control or ticketing operations. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six 39 months and may be updated, replaced, or obsoleted by other documents 40 at any time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on February 2013. 45 . 47 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 62 LLCPS August 2012 64 Table of Contents 66 Abstract........................................................... 1 67 Requirements Language.............................................. 1 68 Status of this Memo................................................ 1 69 Copyright Notice................................................... 2 70 1 Overview......................................................... 4 71 1.1 About the NFC protocol...................................... 4 72 1.2 The LLCP layer.............................................. 6 73 2 TLS support over LLCP............................................ 8 74 2.1 Peer To Peer Link Establishment............................ 10 75 2.2 Inactivity Process......................................... 10 76 2.3.1 Initiator side ...................................... 11 77 2.3.2 Target side ......................................... 11 78 2.3.3 Connection choreography ............................. 12 79 2.4 Disconnection Process...................................... 12 80 2.4.1 Disconnection initiated by the Initiator ............ 12 81 2.4.2 Disconnection initiated by the Target ............... 12 82 2.4.3 Disconnection choreography .......................... 13 83 2.5 Sending Process............................................ 13 84 2.6 Receiving Process.......................................... 15 85 3 Example of LLCPS session........................................ 18 86 3.1 Protocol Activation and Parameters Selection............... 18 87 3.1.1 Initiator ATR-REQ ................................... 18 88 3.1.2 Target ATR-RESP ..................................... 18 89 3.2 LLCP connection............................................ 18 90 3.3 Target: sending Client Hello............................... 19 91 3.4 Inactivity Process......................................... 19 92 3.5 Server: sending Server Hello............................... 19 93 3.6 LLCP Inactivity Process.................................... 20 94 3.7 Client: sending Client Finished............................ 20 95 3.8 Exchanging Data............................................ 21 96 3.8.1 Sending data from client to server .................. 21 97 3.8.2 Sending data from server to client .................. 21 98 3.9 Closing TLS session, initiated by the Initiator............ 22 99 5 Security Considerations......................................... 22 100 4 IANA Considerations............................................. 22 101 6 References...................................................... 22 102 6.1 Normative References....................................... 22 103 6.2 Informative References..................................... 23 104 7 Authors' Addresses.............................................. 23 105 LLCPS August 2012 107 1 Overview 109 1.1 About the NFC protocol 111 The Near Field Communication protocol (NFC) is based on standards 112 such as [ECMA340] or [ISO/IEC 18092]. It uses the 13,56 Mhz 113 frequency, with data rates ranging from 106 To 848 kbps. The working 114 distance between two nodes is about a few centimeters, with 115 electromagnetic fields ranging between 1 and 10 A/M. 117 There are two classes of working operations: 119 - Reader/Writer and Card Emulation. A device named "Reader" feeds 120 another device called "Card", thanks to a 13,56 MHz electromagnetic 121 field coupling. This mode is typically used with [ISO7816] 122 contactless smartcards or with NFC RFIDs. 124 - Peer To Peer (P2P). Two devices, the "Initiator" and the "Target" 125 establish a NFC communication link. In the "Active" mode these two 126 nodes are managing their own energy resources. In the "Passive" mode 127 the Initiator powers the Target via a 13,56 MHz electromagnetic 128 field coupling. 130 This draft focuses on P2P security, which is required by many 131 applications, targeting access control, transport, or other Internet 132 Of Things (IoT) items. Although the NFC protocol enables data 133 exchange at small physical distances, it doesn't support 134 standardized security features providing privacy or integrity. Thus, 135 protocols such as [SNEP] or [NPP], whose goal is to push NDEF [NDEF] 136 contents, are not today secured. In this draft we define a profile 137 for TLS support in P2P operations. 139 A P2P session (see figure 1) occurs in four logical phases: 141 1) Initialization and Anti-collision. The Initiator periodically 142 sends a request packet (and therefore generates a RF field), which 143 is acknowledged by a Target response packet. Because several Targets 144 may be located near the Initiator, an anti-collision mechanism is 145 managed by the Initiator in order to establish a session with a 146 single Target. 147 2) Protocol Activation and Parameters Selection. The Initiator 148 starts a logical session with a detected Target by sending a ATR-REQ 149 (Attribute-Request) message, which is confirmed by a Target ATR-RESP 150 (Attribute-Response) message. These messages fix the device IDs 151 (DIDi, Device ID Initiator and DIDt, Device ID Target) used in 152 further packet exchanges. Optional information fields (Gi for the 153 Initiator, and Gt for the Target) identify the protocol to be used 154 over the MAC level; in this document it is assumed that the LLCP 155 [LLCP] (Logical Link Control Protocol) protocol is selected by the 156 Gi and Gt bytes. Optionally some parameters are negotiated by 157 additional packets. 159 LLCPS August 2012 161 3) Data Exchange. Frames are exchanged via the DEP (Data Exchange 162 Protocol) protocol. DEP works with DEP-REQ (DEP-Request) transmitted 163 by the Initiator and DEP-RESP (DEP-Response) delivered by the 164 Target. DEP provides error detection and recovery. It uses small 165 data unit size (from 64 to 256 bytes); however it supports a 166 chaining mode for larger sizes. DEP frames typically transport LLCP 167 packets, and provide an error free service 168 4) De-Activation. The Initiator may deactivate the Target by sending 169 a RLS-REQ (Release Request) message acknowledged by a RLS-RESP 170 (Release Response). 172 Usually, and for practical reasons, P2P sessions are established 173 between a unique Target and an Initiator, for example a mobile phone 174 and another NFC device. They are automatically started when the 175 distance between the two NFC modes is sufficiently small. The MAC 176 link may be broken at any time, as soon as the distance disables 177 radio operations. 179 Initiator Target 180 | | 181 |<------ (1) Initialization and Anti-Collision ------->| 182 | | 183 |<- (2) Protocol Activation and Parameters Selection ->| 184 | ------------------- ATR-REQ -----------------------> | 185 | <------------------ ATR-RESP ----------------------- | 186 | | 187 |<---------------- (3) Data Exchange ----------------->| 188 | LLCP packets over DEP frames | 189 | TLS over LLCP | 190 | | 191 |<----------------(4) De-Activation ------------------>| 192 | | 194 Figure 1. A NFC P2P Session 196 Due to the dissymmetry of the DEP protocol (see figure 2), in which 197 the Initiator sends requests and Target returns responses, the NFC- 198 P2P MAC services are dissymmetric on the Initiator and Target sides. 200 - The Initiator delivers Data.Request-i and gets Data.Indication-i. 201 - The Target gets Data.Indication-t and delivers Data.Request-t 203 MAC services implemented by NFC controllers usually support such 204 dissymmetric primitives for Initiator and Target procedures (MAC 205 Data.request-i/t and Data.Indication-i/t). 207 The timeout value (between DEP-REQ and DEP-RESP messages) is deduced 208 from the RWT attribute (Response Waiting Time) returned by the 209 Target in the ATR-RESP message. RWT ranges between 0,6 ms and 9,9 210 LLCPS August 2012 212 ms. It may be extended to the RWT-INT by a factor RTOX (RWT-INT = 213 RTOX x RWT) between 1 and 60, so the maximum value is about 6s. 215 Initiator Target 216 | | | | 217 | | | | 218 | Data.Request-i --- DEP-REQ --> Data.Indication-t | 219 | | | 220 | RWT-INT ms | 221 | | | 222 Data.Indication-i <---- DEP-RESP --------- Data.Request-t 224 Figure 2. NFC-P2P MAC layer service, based on DEP frames 226 1.2 The LLCP layer 228 The LLCP [LLCP] protocol works like a light LLC [IEEE 802.2] layer. 229 It provides two classes of services, connectionless transport and 230 connection-oriented transport. 232 This draft focuses on connection-oriented transport because we 233 believe that TLS services MUST be identified by a Service Name (SN). 235 An LLCP packet (see figure 3) comprises three mandatory fields, DSAP 236 (Destination Service Access Point, 6 bits), SSAP (Source Service 237 Access Point, 6 bits), and PTYPE (Protocol data unit type field, 4 238 bits). 240 An optional sequence field (8 bits) contains two 4 bits number N(S) 241 and N(R) respectively giving the number of the information SDU to be 242 sent and the number of the next information PDU to be received. 244 An optional Information field transports the LLCP payload. 246 <--------------LLCP Header--------------><-LLCP Payload -> 247 | DSAP | PTYPE | SSAP | Sequence | INFORMATION | 248 | 6 bits | 4 bits | 6 bits | 0 or 8 bits | M x 8 bits | 250 Figure 3. Structure of an LLCP packet 252 There are sixteen types of LLCP packets, identified by PTYPE values 253 ranging between 0 and 15. In this draft we use only six of these 254 PDUs. 256 1) Symmetry (SYMM, PTYPE=0, DSAP=SSAP=0, no Sequence, no 257 Information). This PDU is produced as soon as there is no 258 information to provide. This mechanism avoids timeout at the MAC 259 (DEP) level. SYMM SHOULD be generated after an inactivity period of 260 about LTO/2, where LTO is the link timeout. 262 LLCPS August 2012 264 2) Connect (CONNECT, PTYPE=4, No sequence, Information). This PDU 265 MUST include a SN (service name parameter) that identified the TLS 266 service ("com.ietf.tls"). It uses a DSAP value set to 1 (the SAP of 267 the Service Discovery Protocol, SDP) and a SSAP value ranging 268 between 16 and 31. It indicates the connection the well-known 269 service (WKS) SDP (SAP=1), which SHOULD deliver an ephemeral SAP 270 (SAP-client) ranging between 16 and 31. 272 3) Connection Complete (CC, PTYPE=6, No sequence, Optional 273 Information). This PDU notifies the successful connection to the 274 "com.ietf.tls" service. It allocates the SAP (DSAP=SAP-client) to be 275 used for this session identified by the tuple (SAP-server, SAP- 276 client) 278 4) Disconnection (DISC, PTYPE=5, No sequence, No Information). This 279 PDU indicates the disconnection of the (SAP-server, SAP-client) 280 session. Null SAP values MAY be used to notify the disconnection of 281 the LLCP entity. 283 5) Disconnected Mode (DM, TYPE=7, No sequence, one byte of 284 Information). This PDU confirms the disconnection of the (SAP- 285 server, SAP-client) session; one information byte gives the 286 "Disconnected Mode Reasons". Null SAP values notify the 287 disconnection of the LLCP entity. 289 6) Information (INFORMATION, PTYPE=10, Sequence, information). This 290 PDU transport a SDU; N(S) indicates the SDU number, N(R) indicates 291 the next SDU number to be received. In this draft the Receive 292 Windows Size (RW) MUST be set to one, which is the default LLCP 293 value. 295 7) Receive Ready (RR, PTYPE=11, sequence N(R) only, no Information). 296 This PDU is used for the acknowledgment of previously received 297 information PDU. It indicates the next sequence number (N(R)) to be 298 received. 300 According to [LLCP] some LLCP functional parameters are updated by 301 LLCP-Parameter attributes exchanged in LLCP packets or in ATR-REQ 302 and ATR-RESP messages. Parameters are encoding according to TLV 303 format, in which Type size is one byte, Length size is one byte and 304 Value is a set of L bytes. In this document we use 6 parameters. 306 1) Version Number (VERSION, T=01h, L=01h, V=10h). In this document 307 this option MUST be included in the general bytes of ATR-REQ and 308 ATR-RESP. 310 2) Maximum Information Unit Extension (MIUX, T=02h, L=02h). This 311 parameter extends the maximum size of the LLCP PDU (MIU), whose 312 default value is 128 bytes, according to the relation: MIU = MIUX + 313 LLCPS August 2012 315 128. The MIUX parameter MAY be inserted in general bytes of ATR-REQ 316 and ATR-RESP, and in LLCP PDUs CONNECT and CC. 318 3) Well-Known Service List (WKS, T=03h, L=02h). This parameter 319 associates a bit to the instance of a well-known LLCP parameter. A 320 typical value is 00001h, indicating the availability of the DSP 321 service. WKS MAY be inserted in general bytes of ATR-REQ and ATR- 322 RESP. 324 4) Link Timeout (LTO, T=04h, L=01h). This parameter indicates the 325 timeout value for the LLCP layer, in multiples of 10ms. LTO MAY be 326 inserted in general bytes of ATR-REQ and ATR-RESP. 328 5) Receive Windows Frame (RW, T=05h, L=01h). This parameter 329 indicates the size of the receive windows, its value ranges between 330 0 and 15. The default value is one, and MUST be set to one according 331 to this document. It MAY be inserted in LLCP PDUs CONNECT or CC. 333 6) Service Name (SN, T=06h). This parameter indicates the name of a 334 service. It MUST be inserted in the CONNECT PDU. In this document 335 its value is set to "com.ietf.tls". 337 2 TLS support over LLCP 339 In NFC P2P mode the Initiator detects a Target and afterwards starts 340 and manages a data exchange session; it may optionally feed the 341 Target device. The Initiator has consequently a longer useful life 342 than the Target; it is a legitimate place to host TLS server in a 343 permanent way. Therefore in this section we assume that the 344 Initiator acts as the TLS server and the Target as the TLS client. 346 Each entity manages five exclusive processes 348 - The Connection Process (CP) 349 - The Disconnection Process (DP) 350 - The Sending Process (SP) 351 - The Receiving Process (RP) 352 - The Inactivity Process (IP) 354 The Inactivity Process MAY be started (see figure 4) each time a 355 receiving or sending buffer is empty; in this case it is assumed 356 that the computing time or the delay required before the next 357 input/output operation is greater than the LLCP timeout (LTO). 359 LLCPS August 2012 361 Initiator Target 362 | | 363 Connection Process Connection Process 364 | | 365 Send SYMM ------------------> Receive SYMM 366 Receive DISC <------------------ Send DISC 367 Send DM -------------------> Receive DM 368 Receive SYMM <------------------- Send SYMM 369 | | 370 =========================TLS Session============================ 371 | | 372 Receiving Process Sending Process 373 | | 374 Send SYMM -------------> Receive SYMM 375 Receive INFORMATION <------------ Send INFORMATION 376 Send RR -------------> Receive RR 377 Receive SYMM <------------- Send SYMM 378 | | 379 Inactivity Process Receiving Process 380 | | 381 Send SYMM ------------------> Receive SYMM 382 Receive SYMM <----------------- Send SYMM 383 | | 384 Sending Process | 385 | | 386 Send INFORMATION ---------------> Receive INFORMATION 387 Receive RR <-------------- Send RR 388 | | 389 Receiving Process Inactivity Process 390 | | 391 Send SYMM -------------------> Receive SYMM 392 Receive SYMM <------------------ Send SYMM 393 | | 394 Send SYMM ------------> Receiving Process 395 Receive INFORMATION <----------- Send INFORMATION 396 Send RR ------------> Receive RR 397 Receive SYMM <----------- Send SYMM 398 | | 399 ===========================End Of TLS Session===================== 400 | | 401 Inactivity Process Inactivity Process 402 | | 403 Disconnection Process | 404 | | 405 Send Disc -------------------> Receive DISC 406 Receive DM <------------------- Send DM 407 | | 409 Figure 4. Overview of Process Operations 410 LLCPS August 2012 412 2.1 Peer To Peer Link Establishment 414 As described in section 1, the Initiator periodically probes the 415 presence of a Target. At the end of the "Protocol Activation and 416 Parameters Selection" phase, ATR-REQ and ATR-RESP messages have been 417 exchanged, and LLCP services are available on both Initiator and 418 Target nodes, including in particular the Data-Request-i/t and Data- 419 Indication-i/t primitives. 421 Due to the ephemeral intrinsic nature of an NFC connection, the P2P 422 session may be broken at any time, which implies transmission or 423 reception errors notified by the MAC primitives. 425 As a consequence an LLCP session is assumed to be released at the 426 first MAC error. 428 2.2 Inactivity Process 430 When the LLCP layer detects an inactivity period greater that a 431 given timeout value (see figure 5), it generates a SYMM PDU. 432 Therefore each time a LLCP layer is waiting for a non SYMM PDU, and 433 receives a SYMM PDU, it MUST acknowledge it by sending a SYMM PDU. A 434 maximum number (SYMM-Ct-i/t) of echoed SYMM PDU SHOULD be defined. 436 Initiator Target 437 | | 438 +------> LLCP inactivity + <-------------+ 439 | | | | 440 | +----------+-----------+ +------------+-----------+ | 441 | + Inactivity Timeout + + Waiting for a LLCP PDU + | 442 | +----------+-----------+ +------------+-----------+ | 443 | | | | 444 | Send SYMM PDU ----> Reception of a PDU | 445 | | | | | 446 | | |SYMM |Other | 447 | Reception of a PDU <---- |Send SYMM PDU |PDU | 448 | | | | | | 449 | SYMM| |Other SYMM-Ct-t++ | | 450 | SYMM-Ct-i++| |PDU | | | 451 +-------------+ +--+ +------------|--------+ 452 | | 453 End Of LLCP Inactivity Send a LLCP PDU 455 Figure 5. Inactivity Process 457 The Inactivity Process (IP) MAY start between the Receiving Process 458 (RP) and the Sending Process (SP). 460 LLCPS August 2012 462 Once a NFC P2P link is established, TLS server and client software 463 entities are activated. Procedures such as: 465 - SOCKET acceptllcp(char *ServiceName), and 466 - SOCKET connectllcp(char *ServiceName) 468 MAY be used respectively on Initiator and Target sides, in order to 469 get a SOCKET. This object supports additional facilities, typically 470 the 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 2.3.1 Initiator side 480 The Initiator MUST transmit a SYMM LLCP PDU. 482 The Initiator MUST receive a CONNECT PDU, with DSAP=1, including the 483 option SN, whose value MUST be set to "com.ietf.tls". If the SN 484 value is incorrect the Initiator transmits a DM PDU with a reason 485 code. 487 The Initiator MUST send a CC PDU, with an SSAP ranging between 16 488 and 31. 490 The Initiator SHOULD receive a SYMM PDU. It MAY receive an 491 INFORMATION PDU but this behavior is not recommended, since it 492 complicates the implementation of the acceptllcp (and connectllcp) 493 procedure. 495 2.3.2 Target side 497 The Target MUST wait for the reception of a SYMM PDU 499 The Target MUST send a CONNECT PDU, with DSAP=1 and SSAP ranging 500 between 16 and 31, including the option SN, whose value MUST be set 501 to "com.ietf.tls. 503 The Target MUST receive a CC PDU. 505 The Target SHOULD send a SYMM PDU. It MAY send an INFORMATION PDU 506 but this behavior is not recommended, since it complicates the 507 implementation of the connectllcp (and acceptllcp) procedure. 509 LLCPS August 2012 511 2.3.3 Connection choreography 513 Initiator Target 514 | | 515 socket= acceptllcp() socket=connectllcp() 516 | | 517 Send SYMMM ------------> Receive SYMM 518 | | 519 Receive CONNECT <------------- Send CONNECT, DSAP=1 520 Check SN SN = "com.ietf.tls" 521 | | 522 Send CC --------------> Receive CC 523 Allocate Ephemeral SAP | 524 | | 525 Receive SYMM <-------------- Send SYMM 526 | | 527 Done Done 529 Figure 6. Connection Choreography 531 2.4 Disconnection Process 533 Due to the ephemeral nature of P2P NFC session, the disconnection 534 process MAY be unavailable. Nerveless it SHOULD be used for a 535 graceful closing of a TLS session. 537 The Disconnection Process is initiated by the Initiator or the 538 Target. 540 2.4.1 Disconnection initiated by the Initiator 542 The Initiator MUST sends a DISC PDU 544 The Target receives the DISC PDU 546 The Target MUST send the DM PDU. 548 The Initiator MUST receive a DM PDU 550 2.4.2 Disconnection initiated by the Target 552 The Target receives an LLCP PDU. If it receives DISC then it sends 553 DM; else it sends the DISC PDU. 555 The target waits for an LLCP PDU. Upon reception of a LLCP PDU it 556 MUST send SYMM. 558 LLCPS August 2012 560 2.4.3 Disconnection choreography 562 Initiator Target 563 | | 564 closellcp(socket) | 565 | | 566 Send DISC --------------> Receive DISC 567 | | 568 Receive DM <-------------- Send DM 569 | | 570 Done 572 Figure 7. Disconnection initiated by the Initiator 574 Initiator Target 575 | | 576 | closellcp(socket) 577 | | 578 Send SYMM -------------> Receive LLCP PDU 579 | | | 580 | | DISC |Other 581 |<-----------------------+ Send DM |(SYMM) 582 | | Done | 583 |<------------------------------------+Send DISC 584 Receive LLCP PDU | 585 | | | 586 [ DM |DISC Receive LLCP PDU 587 | |Send DM | 588 +------------------------------->| 589 | | 590 |<-------------------------------+Send SYMM 591 | | 592 | Done 594 Figure 8. Disconnection initiated by the Target 596 2.5 Sending Process 598 The data transmission is managed by the sendllcp(SOCKET s, char 599 *buffer, int length) procedure. 601 2.5.1 Initiator side 603 The buffer to be transmitted is segmented in LLCP INFORMATION 604 packets. 606 Each packet MUST be acknowledged by the Target with a RR PDU 607 LLCPS August 2012 609 Initiator Target 610 | | 611 Sendllcp(buffer) recvllcp() 612 | | 613 Send INFORMATION PDU -----------------> Receive INFORMATION PDU 614 NS-i++ | 615 | | 616 Receive RR <--------------------------- Send RR(NR-t) 617 | | 618 Send INFORMATION PDU -----------------> Receive INFORMATION PDU 619 NS-i++ | 620 | | 621 Receive RR <--------------------------- Send RR(NR-t) 622 | | 623 Buffer Empty | 624 | 625 Done 627 Figure 9. Sending Process, Initiator side. 629 2.5.2 Target side 631 The Target switches to the sending process, managed by the 632 sendllcp() procedure. 634 The Target MUST receive a SYMM PDU. 636 The buffer to be sent is segmented in INFORMATION PDUs. 638 Each INFORMATION PDU is sent by the Target to the Initiator and MUST 639 be acknowledged by a RR PDU. 641 Upon the reception of the last RR PDU a SYMM PDU MUST be sent by the 642 Target to the Initiator. 644 LLCPS August 2012 646 Initiator Target 647 | | 648 recvllcp() sendllcp(buffer) 649 | | 650 Send SYMM --------> Receive SYMM 651 | | 652 Receive INFORMATION PDU <------- Send INFORMATION PDU 653 | NS-t++ 654 | | 655 SEND RR(NR-i) -------> Receive RR 656 | | 657 Receive INFORMATION PDU <------- Send INFORMATION PDU 658 | NS-t++ 659 | | 660 SEND RR(NR-i) -------> Receive RR 661 | | 662 | Buffer Empty 663 | | 664 Receive SYMM <------- Send SYMM 665 | | 666 Done 668 Figure 10. Sending Process, Target side. 670 2.6 Receiving Process 672 The Receiving process is handled by the recvllcp(SOCKET s, char 673 *buffer, int length) procedure, which manages a reception buffer. 675 2.6.1 Initiator side 677 A1) If the reception buffer is empty, the Initiator sends a SYMM 678 PDU. This PDU starts the Target receiving process. The expected PDU 679 received from the Target is either an INFORMATION PDU or a SYMM PDU 680 (notifying an ephemeral inactivity state). 682 B1) If the reception buffer stores enough data, then the size 683 requested by the recvllcp() procedure is returned. If the buffer 684 gets empty after this operation, a RR PDU is sent to the Target. The 685 PDU received from the Target is either an INFORMATION PDU or a SYMM 686 PDU. 688 B2) Else, while there is not enough data in the buffer, the 689 following loop is performed 690 - Send RR PDU 691 - Receive INFORMATION PDU 693 B2.1) at this end of this loop the size requested by the recvllcp() 694 procedure is returned. If the buffer gets empty after this 695 LLCPS August 2012 697 operation, a RR PDU is sent to the Target. The PDU received from the 698 Target is either an INFORMATION PDU or a SYMM PDU. 700 Initiator Target 701 | | 702 buffer empty sendllcp() 703 | | 704 recvllcp() ===> Send SYMM --------> Receive SYMM 705 | | 706 Receive INFORMATION PDU <------- Send INFORMATION PDU 707 | NS-t++ 708 enough data <=== | | 709 | | 710 recvllcp() ===> | | 711 enough data <=== | | 712 buffer empty | 713 | | 714 Send RR(NR-i) -------> Receive RR 715 | | 716 Receive INFORMATION PDU <------- Send INFORMATION PDU 717 | NS-t++ 718 | | 719 recvllcp() ===> Send RR(NR-i) -------> Receive RR 720 | | 721 Receive INFORMATION PDU <------- Send INFORMATION PDU 722 | NS-t++ 723 enough data <=== | | 724 | | 725 recvllcp() ===> | | 726 Send RR(NR-i) -------> Receive RR 727 | | 728 Receive INFORMATION PDU <------- Send INFORMATION PDU 729 | NS-t++ 730 | | 731 ===> Send RR(NR-i) -------> Receive RR 732 | | 733 Receive INFORMATION PDU <------- Send INFORMATION PDU 734 | NS-t++ 735 enough data <=== | | 736 buffer empty | 737 | | 738 Send RR(NR-i) -------> Receive RR 739 | | 740 | buffer empty 741 | | 742 Receive SYMM <------- Send SYMM 743 | | 744 Done Done 746 Figure 11. Receiving Process, Initiator side. 748 LLCPS August 2012 750 2.6.2 Target side 752 A1) If the reception buffer stores enough data, then the size 753 requested by the recvllcp() procedure is returned. 755 B1) Else, while there is not enough data in the buffer, the 756 following loop is performed 757 - Receive INFORMATION PDU 758 - Send RR PDU 760 Initiator Target 761 | | 762 Sendllcp(buffer) buffer empty 763 | | 764 | | <=== recvllcp() 765 | | 766 Send INFORMATION PDU ----> Receive INFORMATION PDU 767 NS-i++ | 768 | | 769 Receive RR <------------ Send RR(NR-t) 770 | | 771 | | ===> enough data 772 | | 773 | | <=== recvllcp() 774 | | ===> enough data 775 | | 776 | buffer empty 777 | | 778 | | <=== recvllcp() 779 | | 780 Send INFORMATION PDU --> Receive INFORMATION PDU 781 NS-i++ | 782 | | 783 Receive RR <------------ Send RR(NR-t) 784 | | 785 Send INFORMATION PDU --> Receive INFORMATION PDU 786 NS-i++ | 787 | | 788 Receive RR <------------ Send RR(NR-t) 789 | | 790 buffer empty | ===> enough data 791 | buffer empty 792 Done | 793 Done 795 Figure 12. Receiving Process, Initiator side. 797 LLCPS August 2012 799 3 Example of LLCPS session 801 3.1 Protocol Activation and Parameters Selection 803 3.1.1 Initiator ATR-REQ 805 Raw-data: 806 5C A9 BE E1 C0 35 A0 BF 16 0F 00 00 00 02 46 66 807 6D 01 01 10 03 02 00 01 04 01 01 10 64 809 NFCID3i= 5C A9 BE E1 C0 35 A0 BF 16 0F 810 DIDi (Initiator ID) = 00 811 BSi= 00 812 BRi= 00 813 PPi= 02, 64 bytes of Transport Data, Gt bytes available 814 Magic Bytes: 46666d 815 Option: Version, Major=1, Minor=0 816 Option: WKS: Well-Known Service List 0x0001 817 Option: LTO: Link TimeOut 0x64 (1000 ms) 819 3.1.2 Target ATR-RESP 821 Raw-Data: 822 AA 99 88 77 66 55 44 33 22 11 00 00 00 09 03 46 823 66 6D 01 01 10 03 02 00 01 04 01 64 825 NFCID3t= AA 99 88 77 66 55 44 33 22 11 826 DIDt (Target ID)= 00 827 BSt= 00 828 BRt= 00 829 TO= 09, WT= 6363 ms 830 PPt= 03, 64 bytes of Transport Data, NAD available, Gt bytes 831 available 832 Magic Bytes: 46666d 833 Option: Version, Major=1, Minor=0 834 Option: WKS: Well-Known Service List 0x0001 835 Option: LTO: Link TimeOut 0x64 (1000 ms) 837 3.2 LLCP connection 839 Initiator: Sending SYMM, ssap=0 dsap=0 840 Tx-i: 00 00 841 Target: Sending CONNECT, ssap=27 dsap=1, option=SN("com.ietf.tls") 842 Rx_i: 05 1B 06 0C 63 6F 6D 2E 69 65 74 66 2E 74 6C 73 843 Initiator: Sending ConnectionComplete, ssap=16 dsap=27 844 Tx-i: 6D 90 845 Target: Sending SYMM, ssap=0 dsap=0 846 Rx-i: 00 00 847 LLCPS August 2012 849 3.3 Target: sending Client Hello 851 RecvLLCP Initiator: request size=5, buffer empty, sending SYMM 852 Initiator: Sending SYMM, ssap=0 dsap=0 853 Tx-i: 00 00 855 SendLLCP Target: request size=82 bytes, Waiting for SYMM 856 Target: Receiving SYMM, ssap=0 dsap=0 857 Target: Sending INFORMATION, ssap=27 dsap=16 Nr=0, Ns=0 858 Rx-i: 43 1B 00 16 03 01 00 4D 01 00 00 49 03 01 50 1A 859 A9 6B 82 55 1C B5 AD FF BC 87 21 66 5F B5 98 41 860 9E 17 33 39 45 F9 78 86 46 D6 F6 75 51 10 20 E7 861 0A 41 FE 8C F9 A0 38 D3 28 72 E8 04 7E C2 37 22 862 05 13 24 AA DE 2F 6B 67 4C 19 CE A5 7D A0 86 00 863 02 00 04 01 00 865 RecvLLCP_Initiator: request size=5 bytes, buffer=82 bytes 866 RecvLLCP_Initiator: request size=77 bytes, buffer=77 bytes 867 RecvLLCP_Initiator: buffer empty, sending RR(1), ssap=16 dsap=27 868 Tx-i: 6F 50 01 870 SendLLCP_Target: Receiving RR(1), ssap=16 dsap=27 871 SendLLCP_Target: empty buffer, Done, Sending SYMM 872 Target: Sending SYMM, ssap=0 dsap=0 874 Initiator: Receiving SYMM ssap=0 dsap=0 875 Rx-i: 00 00 877 3.4 Inactivity Process 879 Initiator: Sending SYMM, ssap=0 dsap=0 880 Tx-i: 00 00 882 RecvLLCP Target: request size=5 bytes, buffer empty 883 Target: Receiving SYMM, ssap=0 dsap=0 884 Target: Sending SYMM, ssap=0 dsap=0 886 Initiator: Receiving SYMM, ssap=0 dsap=0 887 Rx-i: 00 00 889 3.5 Server: sending Server Hello 891 SendLLCP_Initiator: request size=122 bytes 892 Initiator: Sending INFORMATION, ssap=16 dsap=27 Nr=1 Ns=0 893 Tx-i: 6F 10 01 16 03 01 00 4A 02 00 00 46 03 01 50 1A 894 A9 6B 6C 0E 31 E1 F3 0E CD 18 E7 6F 81 BF 5F 3C 895 FD DE 00 4C A4 12 AE DC DF E4 FF 82 09 5E 20 E7 896 0A 41 FE 8C F9 A0 38 D3 28 72 E8 04 7E C2 37 22 897 05 13 24 AA DE 2F 6B 67 4C 19 CE A5 7D A0 86 00 898 04 00 14 03 01 00 01 01 16 03 01 00 20 83 18 D1 899 LLCPS August 2012 901 E3 BC 3A 94 26 91 3D FC F3 8E 01 46 5E 52 8E 67 902 A2 66 FC 5F D5 89 78 59 66 14 BA D3 B0 904 RecvLLCP_Target: Receiving INFORMATION, ssap=16 dsap=27 Nr=1 Ns=0 905 RecvLLCP_Target: sending RR(1), ssap=27 dsap=16 906 RecvLLCP_Target: request size=74 bytes 907 RecvLLCP_Target: request size=5 bytes 908 RecvLLCP_Target: request size=1 byte 910 SendLLCP Initiator: Receiving RR(1), ssap=27 dsap=16 911 Rx-i: 43 5B 01 912 SendLLCP_Initiator: buffer empty, Done 914 RecvLLCP_Target: request size=5 bytes 915 RecvLLCP_Target: request size=32 bytes, Done, empty buffer 917 3.6 LLCP Inactivity Process 919 RecvLLCP_Initiator: request size=5, empty buffer, sending SYMM 920 Initiator: Sending SYMM, ssap=0 dsap=0 921 Tx-i: 00 00 923 Target: Receiving SYMM, ssap=0 dsap=0 924 Target: Sending SYMM, ssap=0 dsap=0 926 Initiator: Receiving SYMM ssap=0 dsap=0 927 Rx-i: 00 00 929 3.7 Client: sending Client Finished 931 Initiator: Receiving SYMM ssap=0 dsap=0 932 Tx-i: 00 00 934 SendLLCP_Target: request size=43 bytes, Waiting for SYMM 935 Target: Receiving SYMM, ssap=0 dsap=0 936 Target: Sending INFORMATION, ssap=27 dsap=16 Nr=1, Ns=1 937 Rx-i: 43 1B 11 14 03 01 00 01 01 16 03 01 00 20 57 DD 938 DE 29 9E E4 EF DD C5 18 87 50 C6 C7 B9 56 AD FA 939 EF 65 B2 24 48 04 2E FE 7D BD 97 E1 F3 3A 941 Initiator: Receiving INFORMATION, ssap=27 dsap=16 Nr=1, Ns=1 942 RecvLLCP_Initiator: request size= 5 bytes, buffer=43 bytes 943 RecvLLCP_Initiator: request size= 1 bytes, buffer=38 bytes 944 RecvLLCP_Initiator: request size= 5 bytes, buffer=37 bytes 945 RecvLLCP_Initiator: request size=32 bytes, buffer=32 bytes 946 RecvLLCP_Initiator: empty buffer, sending RR(2) 947 Initiator: Sending RR(2), ssap=16 dsap=27 948 Tx-i: 6F 50 02 950 Target: Receiving RR(2), ssap=16 dsap=27 Nr=2 951 LLCPS August 2012 953 SendLLC_Target: empty buffer, Done, sending SYMM 954 Target: Sending SYMM, ssap=0 dsap=0 956 Initiator: Receiving SYMM ssap=0 dsap=0 957 Rx-i: 00 00 959 3.8 Exchanging Data 961 3.8.1 Sending data from client to server 963 RecvLLCP_Initiator: request size=5 bytes, empty buffer, sending SYMM 964 Initiator: Sending SYMM, ssap=0 dsap=0 965 Tx-i: 00 00 967 Target: Receiving SYMM, ssap=0 dsap=0 968 SendLLCP_Target: sending 27 bytes 969 Target: Sending INFORMATION, ssap=27 dsap=16 Nr=1, Ns=2 971 Initiator: Receiving INFORMATION, ssap=27 dsap=16 Nr=1, Ns=2 972 Rx-i: 43 1B 21 17 03 01 00 16 C2 D5 18 CB 0D AB 44 E5 973 0F 25 DB 83 6D 26 B7 74 E7 90 EF 33 8C FE 974 RecvLLCP_Initiator: request size= 5 bytes, buffer=27 bytes 975 RecvLLCP_Initiator: request size=22 bytes, buffer=22 bytes 976 Initiator: Sending RR(3), ssap=16 dsap=27 977 Tx-i: 6F 50 03 979 Target: Receiving RR(3), ssap=16 dsap=27 980 SendLLC_Target: empty buffer, Done, sending SYMM 981 Target: Sending SYMM, ssap=0 dsap=0 983 Initiator: Receiving SYMM ssap=0 dsap=0 984 Rx-i: 00 00 986 3.8.2 Sending data from server to client 988 SendLLCP Initiator: request size=27 bytes 989 Initiator: Sending INFORMATION, ssap=16 dsap=27 Nr=3 Ns=1 990 Tx-i: 6F 10 13 17 03 01 00 16 DC 82 FE B9 EA 1C 63 5C 991 AC 8C FE C9 A2 4F 8A FD 54 EE 18 F5 DB 30 993 RecvLLCP_Target: request size= 5 bytes 994 Target: Receiving INFORMATION, ssap=16 dsap=27 Nr=3 Ns=1 995 RecvLLCP_Target: sending RR(2) 996 Target: Sending RR(2), ssap=27 dsap=16 997 RecvLLCP_Target: request size=22 bytes, buffer=22 bytes, Done 999 Initiator: Receiving RR(2), ssap=27 dsap=16 1000 Rx-i: 43 5B 02 1001 SendLLCP Initiator: empty buffer, Done 1002 LLCPS August 2012 1004 3.9 Closing TLS session, initiated by the Initiator 1006 Initiator: Sending DISC, ssap=16 dsap=27 1007 Tx-i: 6D 50 1009 Target: Receiving DISC, ssap=16 dsap=27 1010 Target: Sending DM, ssap=27 dsap=16 1012 Initiator: Receiving DM, ssap=27 dsap=16 1013 Rx-i: 41 DB 00 1015 5 Security Considerations 1017 To be done. 1019 4 IANA Considerations 1021 6 References 1023 6.1 Normative References 1025 [TLS 1.0] Dierks, T., C. Allen, "The TLS Protocol Version 1.0", RFC 1026 2246, January 1999 1028 [TLS 1.1] Dierks, T., Rescorla, E., "The Transport Layer Security 1029 (TLS) Protocol Version 1.1", RFC 4346, April 2006 1031 [TLS 1.2] Dierks, T., Rescorla, E., "The Transport Layer Security 1032 (TLS) Protocol Version 1.1", draft-ietf-tls-rfc4346-bis-10.txt, 1033 March 2008 1035 [ECMA340] "Near Field Communication Interface and Protocol (NFCIP- 1036 1)", Standard ECMA-340, December 2004 1038 [ISO/IEC 18092] "Information technology - Telecommunications and 1039 information exchange between systems - Near Field Communication - 1040 Interface and Protocol (NFCIP-1)", April 2004 1042 [LLCP] "Logical Link Control Protocol", Technical Specification, NFC 1043 ForumTM, LLCP 1.1, June 2011 1045 [SNEP] "Simple NDEF Exchange Protocol", Technical Specification, NFC 1046 ForumTM, SNEP 1.0, August 2011 1048 [NDEF] "NFC Data Exchange Format (NDEF)", Technical Specification 1049 NFC ForumTM, NDEF 1.0, July 2006. 1051 LLCPS August 2012 1053 [ISO7816] ISO 7816, "Cards Identification - Integrated Circuit Cards 1054 with Contacts", The International Organization for Standardization 1055 (ISO) 1057 [IEEE 802.2] IEEE Std 802.2, "IEEE Standard for Information 1058 technology Telecommunications and information exchange between 1059 systems Local and metropolitan area networks, Specific requirements, 1060 Part 2: Logical Link Control", 1998 1062 6.2 Informative References 1064 [NPP} "Android NDEF Push Protocol Specification Version 1", February 1065 2011 1067 7 Authors' Addresses 1069 Pascal Urien 1070 Telecom ParisTech 1071 23 avenue d' Italie 1072 75013 Paris Phone: NA 1073 France Email: Pascal.Urien@telecom-paristech.fr