idnits 2.17.1 draft-ohba-pana-potls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1518 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 25 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 166: '...l authentication MAY be performed over...' RFC 2119 keyword, line 207: '... associated with a TLS connection MUST...' RFC 2119 keyword, line 210: '...sport connection MUST be terminated wh...' RFC 2119 keyword, line 212: '... connection MUST be kept open as lon...' RFC 2119 keyword, line 215: '...ransport connection MAY be terminated....' (30 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [Keywords], but that reference does not seem to mention RFC 2119 either. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 30, 2002) is 7871 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'PAADiscover' is mentioned on line 491, but not defined == Missing Reference: 'AuthRequest' is mentioned on line 519, but not defined == Unused Reference: 'DHCPAUTH' is defined on line 1137, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2284 (ref. 'EAP') (Obsoleted by RFC 3748) == Outdated reference: A later version (-10) exists of draft-ietf-pppext-rfc2284bis-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'Keywords' -- Possible downref: Non-RFC (?) normative reference: ref. 'PANAREQ' -- Possible downref: Non-RFC (?) normative reference: ref. 'PANAUSAGE' -- Possible downref: Non-RFC (?) normative reference: ref. 'PIC' ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Yoshihiro Ohba/Shinichi Baba 3 Expires: March, 2003 Toshiba America Research, Inc. 4 Subir Das 5 Telcordia Technologies 7 September 30, 2002 9 PANA over TLS 11 13 Status of This Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC 2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents, valid for a maximum of six 24 months, and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This draft specifies a method to carry authentication information 37 over TLS between PANA Client (PaC) and PANA Authentication Agent 38 (PAA). PANA over TLS uses existing TLS protocol over a reliable 39 transport in order to perform authentication information exchange in 40 a secure and reliable manner. The purpose of this document is not 41 only to provide a mechanism for carrying the authentication 42 parameters but also to address some outstanding issues such as, 43 multiple access routers, reauthentication, security threats, etc. 45 Expires March, 2003 [Page 1]^L 46 Table of Contents 48 1 Introduction ............................................ 2 49 2. Requirements Language ................................... 3 50 3. Protocol Overview ....................................... 3 51 4. Protocol Specification .................................. 4 52 4.1. TLS Session, TLS Connection and Transport Connection .... 4 53 4.2. Transport Layer Protocol ................................ 5 54 4.3. PAA Discovery ........................................... 5 55 4.3.1. Manual Configuration .................................... 5 56 4.3.2. Notification from PAA ................................... 5 57 4.3.3. DHCP .................................................... 6 58 4.3.4. Multicast Query ......................................... 6 59 4.4. Authentication Modes .................................... 6 60 4.5. Authentication Types .................................... 6 61 4.6. Multi-level Authentication .............................. 7 62 4.7. Protecting Device Identifiers ........................... 7 63 4.8. Authenticated Heartbeat Protocol ........................ 8 64 4.9. Deriving Purpose-Specific Keys .......................... 8 65 4.10. Message Flows ........................................... 9 66 4.11. Message Formats and Processing Rules ................... 10 67 4.11.1. PAADiscover Message .................................... 11 68 4.11.2. AuthRequest Message .................................... 12 69 4.11.3. DeviceID Message ....................................... 12 70 4.11.4. AuthInfo Message ....................................... 14 71 4.11.5. Success Message ........................................ 15 72 4.11.6. Failure Message ........................................ 16 73 4.11.7. Error Message .......................................... 16 74 4.11.8. Heartbeat Message ...................................... 18 75 5. Protocol Parameters .................................... 19 76 6. Security Consideration ................................. 19 77 6.1 Security on PAA Discovery .............................. 19 78 6.2 Security on Transport Connection for TLS ............... 20 79 6.3 Security on TLS Handshake .............................. 20 80 6.4 Security on PANA Message Exchange over TLS Connection .. 20 81 7. Possible Future Direction .............................. 21 82 8. Acknowledgments ........................................ 21 83 9. References ............................................. 21 84 10. Authors' Information ................................... 22 86 1 Introduction 88 This protocol, PANA over TLS (Protocol for carrying Authentication 89 for Network Access over Transport Layer Security), is designed for 90 authentication message exchange between PaC and PAA, both of which 91 are on the same subnet [PANAREQ]. 93 PANA over TLS uses TLS [TLS] over a reliable transport in order to 94 perform authentication information exchange in a secure and reliable 95 manner. In particular, the security features provided with TLS are 96 important for providing encryption and/or integrity protection for 97 the entire authentication protocol exchange including the identity of 98 the client as well as authentication result (e.g., EAP- 99 Success/Failure) that is not protected in some authentication 100 protocol such as EAP [EAP]. Without protecting those information it 101 is difficult to distinguish the case where authentication is failed 103 Expires March, 2003 [Page 2]^L 104 due to invalid credentials from other errors that might have happened 105 as a result of some active attack. 107 There are a number of protocols such as IKE (Internet Key Exchange) 108 [IKE] and PIC (Pre-IKE Credential provisioning) [PIC] that could be 109 used for protecting authentication message exchange over a secure 110 communication channel. However, TLS is selected in this protocol for 111 the following reasons. 113 First, unlike IKE, TLS does not require mutual authentication for 114 establishing a secure communication channel between peer entities. 115 It would not be a realistic requirement for assuming mutual 116 authentication especially in roaming environments. Second, unlike 117 PIC, TLS supports a session resumption functionality that can be used 118 for making re-authentication faster than that is performed without 119 session resumption. 121 PANA over TLS is designed for carrying any authentication protocol 122 information including EAP messages. It is also possible to use a TLS 123 certificate for authenticating a PaC without using any other 124 authentication protocol. PANA over TLS supports combining multiple 125 types of authentication to authenticate a PaC. For example, it is 126 possible to use a TLS client certificate for authenticating an IP 127 address of the PaC and then use EAP for authenticating the user of 128 the PaC. 130 PANA over TLS also defines a Device Identifier [PANAREQ] protection 131 mechanism to protect man-in-the-middle attacks against transport 132 connections by spoofing MAC/IP address while man-in-the-middle 133 attacks against contents carried over TLS connections are protected 134 by TLS. 136 2. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [Keywords]. 142 3. Protocol Overview 144 In this protocol authentication information is carried between a PaC 145 and a PAA over a secure TLS connection on top of a reliable transport 146 protocol such as TCP and SCTP. The PaC and the PAA are the client 147 and the server of the TLS connection, respectively. The TLS 148 connection is established based on the TLS Handshake Protocol defined 149 in [TLS]. 151 When authentication information is carried over a TLS connection, 152 confidentiality and integrity for the authentication information 153 exchange between the PaC and PAA are provided by the TLS connection. 154 Reliability, congestion control and fragmentation free communication 155 are provided by the reliable transport (though TLS also handles 156 fragmentation). 158 To establish a TLS connection a PaC needs to find (an) IP address(es) 160 Expires March, 2003 [Page 3]^L 161 of the PAA(s) on the link. PAA Discovery described in this document 162 is used for this purpose. 164 It is possible to use a TLS client certificate that is optionally 165 carried during a TLS handshake as the credential of PaC. In this 166 case, additional authentication MAY be performed over the TLS 167 connection. 169 In order to avoid Device Identifier spoofing, PANA over TLS also 170 supports exchanging Device Identifier information over the TLS 171 connection. 173 PANA over TLS supports fast authentication based on the session 174 resumption functionality of TLS [TLS]. 176 The security association corresponding to the master secret of the 177 TLS session established between PaC and PAA is considered to be a 178 Local Security Association (LSA) from which other security 179 association can be derived. The TLS master secret can be used for 180 deriving any kind of security association. 182 PANA over TLS is designed to work over both multi-access links and 183 point-to-point links (this does not necessary mean PPP links, an IP- 184 in-IP tunnel and a GRE tunnel are also point-to-point). The only 185 requirement is the PaC and PAA is on the same link in order to 186 discover PAAs based on link-local multicast. 188 4. Protocol Specification 190 4.1. TLS Session, TLS Connection and Transport Connection 192 A TLS connection is a secure data channel over which application data 193 is securely exchanged between TLS peers. Most of the messages 194 defined in this protocol are carried over TLS connections. 196 A TLS session is a signaling channel used for establishing a master 197 secret shared between TLS peers and establishing a TLS connection by 198 negotiating cipher suites based on the master secret. The lifetime 199 of a TLS session can be longer than that of a TLS connection, i.e., 200 after terminating a TLS connection a new TLS connection can be 201 established or an existing suspended TLS connection can be reused 202 within the same TLS session (TLS session resumption). As specified 203 in [TLS], TLS Alert/close_notify messages need to be exchanged before 204 terminating the TLS connection in order for a session to be able to 205 be resumed later. 207 A transport connection that is associated with a TLS connection MUST 208 be terminated when the current TLS connection is terminated. 209 Similarly, the current TLS connection that is associated with a 210 transport connection MUST be terminated when the transport connection 211 is terminated. After successful authentication, the transport 212 connection MUST be kept open as long as the PaC is authorized for 213 network access when Authenticated Heartbeat Protocol (AHP) is used 214 for detecting implicit disconnection of a PaC. Otherwise, the 215 transport connection MAY be terminated. 217 Expires March, 2003 [Page 4]^L 218 4.2. Transport Layer Protocol 220 PANA over TLS uses TCP or SCTP as the TLS transport. SCTP is 221 preferable since it has a cookie-based 4-way handshake mechanism to 222 protect against masquerade attacks (e.g., TCP SYN attacks) for 223 transport connections. 225 UDP is also used for carrying messages used for finding (an) IP 226 address(es) of PAA(s) and requesting (re-)authentication from PAA(s). 228 Both PaC and PAA need to configure an IP address before running this 229 protocol. In IPv6, a link-local address can be used for this 230 protocol. In IPv4, the IP address that is currently assigned to the 231 interface is used. 233 The same port number PortNumber is used for TCP, SCTP and UDP. 235 4.3. PAA Discovery 237 /* Authors' note: 239 For ease of understanding and completeness of this document the 240 following section has been described here. However, the authors 241 recognize that PAA discovery is a problem by itself and need further 242 discussions. 244 */ 246 Assuming that PAA is not co-located with an access router, a 247 discovery mechanism is necessary for determining an IP address of the 248 PAA. In addition, there may be multiple enforcement points and all 249 of them may or may not be controlled by a single PAA. Methods that 250 are used for a PaC to choose one or more PAAs when there are multiple 251 PAAs in the same subnet are for further study. In any situation, a 252 PAC needs to be aware of at least an IP address of each PAA and such 253 information can be obtained by using at least one of the following 254 ways: 256 1. Manual configuration 258 2. Notification from PAA 260 3. DHCP 262 4. Multicast query 264 Each method is explained below. 266 4.3.1. Manual Configuration 268 This is entirely specific to implementation and not described in this 269 document. 271 4.3.2. Notification from PAA 273 Expires March, 2003 [Page 5]^L 274 When a PAA detects that a new PaC device is connected to the subnet, 275 it MAY send an AuthRequest message to the PaC. The AuthRequest 276 message is unicast over UDP. The PaC that receives an AuthRequest 277 message will start establishing a TLS connection with the PAA. The 278 PaC SHOULD NOT start establishing a TLS connection when it receives 279 an from a PAA if it is in mid of performing authentication with the 280 PAA. How a PAA detects the presence of a new PaC is out of the scope 281 of this document. 283 4.3.3. DHCP 285 A new DHCP configuration option needs to be defined to carry the 286 information described above. 288 4.3.4. Multicast Query 290 When PAA Discovery is performed via multicast, a PaC sends a 291 PAADiscover message over a specific link-local multicast address 292 "All-PAA-Nodes." Each PAA that received the message responds with an 293 AuthRequest message. The AuthRequest message is unicast over UDP. A 294 PAA SHOULD silently discard a PAADiscovery message received from a 295 PaC without responding with a AuthRequest if it is mid of performing 296 authentication with the PaC. 298 In the case of IPv4, All-PAA-Nodes is the same as "all-hosts" group 299 (224.0.0.1). In the case of IPv6, All-PAA-Nodes is a link-local 300 scoped multicast address to be assigned by IANA. 302 All PAAs MUST support this method. 304 4.4. Authentication Modes 306 There are two modes of authentication: Full authentication and Fast 307 Authentication. Full Authentication is performed when a new TLS 308 session is established with a full TLS handshake. A new session ID 309 is allocated for the session. For Full Authentication, a server 310 certificate MUST be used in TLS handshake to avoid a man-in-the- 311 middle attack where TLS connections are spliced at an intermediate 312 eavesdropper. 314 Fast Authentication is performed based on an existing TLS session by 315 using the session resumption functionality of TLS. A PaC can always 316 propose Fast Authentication whenever it has a TLS session with the 317 PAA. Fast Authentication is performed by specifying the session ID 318 of the existing TLS session. On the other hand, The PAA can always 319 choose to either perform Fast Authentication or force Full 320 Authentication for the PaC that is proposing Fast Authentication with 321 an existing session ID. 323 4.5. Authentication Types 325 There are two types of authentication defined for Full Authentication 326 mode: Non-TLS Authentication and TLS Authentication. In Non-TLS 328 Expires March, 2003 [Page 6]^L 329 Authentication, a PaC is authenticated without using a TLS client 330 certificate. In Non-TLS Authentication, a PAA MUST NOT request a TLS 331 client certificate during a TLS handshake, and AuthInfo message 332 exchange MUST be performed over the TLS connection. In TLS 333 Authentication, a TLS client certificate MUST be used during TLS 334 handshake for authenticating a PaC and additional AuthInfo message 335 exchange MAY be performed over the TLS connection. There is no 336 distinction in authentication type for Fast Authentication. 338 4.6. Multi-level Authentication 340 PANA over TLS supports multi-level authentication in which multiple 341 legs of "sub-authentication" may be performed one by one until a PaC 342 is finally authenticated by a PAA. For example, in the case of TLS 343 authentication with AuthInfo message exchange, authentication during 344 TLS session negotiation with a TLS client certificate can be a sub- 345 authentication leg and authentication based on AuthInfo message 346 exchange can be another sub-authentication leg. Or when EAP message 347 is carried in AuthInfo message, multi-level authentication can be 348 performed within EAP [EAPBIS]. 350 When multi-level authentication occurs, it is the matter of 351 authorization policy whether the entire sub-authentication legs need 352 to be successful in order for a PaC to be finally authenticated or a 353 restricted level of authorization may be applied when only a portion 354 of the entire sub-authentication legs is successful, except that TLS 355 authentication always requires successful TLS client certificate 356 authentication to establish a TLS session. Such an authorization 357 policy issue is out of the scope of this document. 359 4.7. Protecting Device Identifiers 361 Although TLS server certificates used for TLS handshake prevents man- 362 in-the-middle attacks against TLS connections, another type of man- 363 in-the-middle attack is still possible against transport connections. 364 That is, an intermediate attacker may splice two transport 365 connections that carry the contents of a single TLS connection 366 between a PaC and a PAA without any modification. As a result, the 367 attacker can successfully make its own IP address authorized for 368 network access instead of the IP address of the PaC. Also, if a TLS 369 server certificate is not directly associated with an IP address of 370 the PAA, it is also possible for the intermediate attacker to be a 371 rogue PAA (the TLS server certificate may be associated with a FQDN, 372 but the FQDN may result in being mapped to a different IP address if 373 DNS is not secured). 375 To deal with the man-in-the-middle attack against transport 376 connections, PANA over TLS defines a Device Identifier exchange 377 mechanism over TLS connections. DeviceID message is used for this 378 purpose. 380 If a received Device Identifier contained in a DeviceID message sent 381 from the peer is different from that is actually specified in the IP 382 and/or MAC header(s) of the underlying transport connection, the PAA 383 MUST return an Error message and immediately terminate the TLS 385 Expires March, 2003 [Page 7]^L 386 connection and transport connection. 388 4.8. Authenticated Heartbeat Protocol 390 PANA over TLS defines Authenticated Heartbeat Protocol (AHP) in which 391 short messages (i.e., Heartbeat) are exchanged over the TLS 392 connections in order to detect an inactive PaC without allowing an 393 attacker to be able to gain authorized network access by spoofing the 394 IP address of the legitimate PaC. Both Fast Authentication and AHP 395 can be used for local re-authentication in which re-authentication is 396 performed locally between PaC and PAA based on an established local 397 security association (i.e., the TLS session) between them 398 [PANAUSAGE]. Re-authentication can be performed faster by AHP than 399 by Fast Authentication at the cost of holding the transport 400 connection. AHP MUST be used if the layer 2 entity does not provide 401 device disconnect indication to higher layer entities. 403 A PAA can send a Heartbeat/Request message whenever it needs to check 404 whether the PaC is active or not. The PaC is requested to send a 405 Heartbeat/Response message in response to the Heartbeat/Request 406 message. Heartbeat/Request message MAY be sent periodically. 408 AHP starts after successful Full or Fast Authentication. When AHP is 409 used, the transport connection MUST remain established. The PaC 410 device is considered to be inactive when no Heartbeat message is 411 received within a Heartbeat/Response timeout period, and an 412 appropriate action SHOULD be taken by the PAA for the device, e.g., 413 deleting the authorized status at the enforcement point(s) controlled 414 by the PAA. 416 DefaultHeartbeatTimeout is the default timeout value for 417 Heartbeat/Response. 419 A PaC that is running AHP may determine to disconnect from the 420 network. If this happens, it MAY terminate the TLS connection and 421 the transport connection without terminating the TLS session for 422 future Fast Authentication based on session resumption. This is 423 achieved by exchanging TLS Alert/close_notify messages between peers 424 before terminating the TLS connection and the transport connection. 426 4.9. Deriving Purpose-Specific Keys 428 The master secret of an established TLS session can be used for 429 deriving a cryptographic key that can be used for a specific purpose. 430 This purpose-specific key can be used by some other protocols for 431 their client/server authentication. This document describes a 432 generic rule for deriving such a purpose-specific key. 434 purpose_specific_key = PRF(SecurityParameters.master_secret, 435 PURPOSE_SPECIFIC_STRING, 436 SecurityParameters.server_random + 437 SecurityParameters.client_random). 439 The definition of the PRF function and the structure of 440 SecurityParameters are specified in [TLS]. 442 Expires March, 2003 [Page 8]^L 443 PURPOSE_SPECIFIC_STRING is an ASCII string that is defined for each 444 purpose and is never carried in this protocol. Actual string values 445 for PURPOSE_SPECIFIC_STRING and detailed key derivation and usage 446 rules depend on each purpose, and thus are not defined in this 447 document. 449 4.10. Message Flows 451 Message flows for possible combination of authentication types and 452 modes are illustrated in Figures 1 through 3. In these figures, 453 messages marked with * are defined in this protocol and carried over 454 the secure TLS connection as application data. Messages not marked 455 with * are TLS signaling messages defined in [TLS], except for 456 PAADiscover and AuthRequest messages that are carried over UDP. 457 Messages surrounded in a pair of square brackets are optional. 458 Although this protocol can carry any authentication protocol 459 information, EAP messages are typically carried in AuthInfo messages. 461 PaC PAA 463 [PAADiscover] --------> 464 <-------- [AuthRequest] 466 ClientHello --------> 467 ServerHello 468 Certificate 469 ServerKeyExchange 470 <-------- ServerHelloDone 471 ClientKeyExchange 472 CertificateVerify 473 ChangeCipherSpec 474 Finished --------> 475 ChangeCipherSpec 476 <-------- Finished 477 DeviceID* <-------> DeviceID* 478 AuthInfo* <-------> AuthInfo* 479 . 480 . 481 <-------- Success/Failure* 482 [Heartbeat*] <-------> [Heartbeat*] 483 . 484 . 486 Figure 1: Message Flow for Full Non-TLS Authentication 488 Expires March, 2003 [Page 9]^L 489 PaC PAA 491 [PAADiscover] --------> 492 <-------- [AuthRequest] 493 ClientHello --------> 494 ServerHello 495 Certificate 496 ServerKeyExchange 497 CertificateRequest 498 <-------- ServerHelloDone 499 Certificate 500 ClientKeyExchange 501 CertificateVerify 502 ChangeCipherSpec 503 Finished --------> 504 ChangeCipherSpec 505 <-------- Finished 506 DeviceID* <-------> DeviceID* 507 [AuthInfo*] <-------> [AuthInfo*] 508 . 509 . 510 <-------- Success/Failure* 511 [Heartbeat*] <-------> [Heartbeat*] 512 . 513 . 515 Figure 2: Message Flow for Full TLS Authentication 517 PaC PAA 519 <-------- [AuthRequest] 520 ClientHello --------> 521 ServerHello 522 ChangeCipherSpec 523 <-------- Finished 524 ChangeCipherSpec 525 Finished --------> 526 DeviceID* <-------> DeviceID* 527 <-------- Success/Failure* 528 [Heartbeat*] <-------> [Heartbeat*] 529 . 530 . 532 Figure 3: Message Flow for Fast Authentication 534 4.11. Message Formats and Processing Rules 536 In this specification, all multi-octet fields are encoded in network 537 byte order. 539 All messages defined in this document start with the following 540 header. 542 Expires March, 2003 [Page 10]^L 543 1 2 3 544 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Type | Subtype | Length | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 Type 551 A type of the message. 553 Subtype 555 A type-specific information needed for decoding the message 556 payload. The Subtype name "NoSubtype" indicates that there is no 557 subtype for that Type. 559 Length 561 An unsigned 2-octet integer that contains the length of the 562 message in octets, including the header and payload of the 563 message. 565 4.11.1. PAADiscover Message 567 When this message will be sent: 569 This message is multicast over UDP by a PaC needs to know (an) IP 570 address(es) of PAA(s) to perform Full Authentication. 572 Meaning of this message: 574 This message means that the sender PaC is searching PAA(s). When a 575 PAA receives this message from a PaC, it SHOULD return a 576 AuthRequest message to the PaC unless if it is in mid of 577 authentication with the PaC. 579 Structure of this message: 581 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Type | Subtype | Length | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Type 588 Type value Type name 590 0x01 PAADiscover 592 Subtype 594 Subtype value Subtype name 596 0x00 NoSubtype 598 Expires March, 2003 [Page 11]^L 599 Length 601 The Length value is 4. 603 Payload 605 The payload is null. 607 4.11.2. AuthRequest Message 609 When this message will be sent: 611 This message is sent over UDP by a PAA when Full or Fast 612 Authentication is needed. 614 Meaning of this message: 616 When a PaC receives this message, it starts Full or Fast 617 Authentication if the PaC device needs to be authorized for network 618 access. The PaC SHOULD NOT start establishing a TLS connection 619 when it receives an from a PAA if it is in mid of performing 620 authentication with the PAA. 622 Structure of this message: 624 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Type | Subtype | Length | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 Type 631 Type value Type name 633 0x02 AuthRequest 635 Subtype 637 Subtype value Subtype name 639 0x00 NoSubtype 641 Length 643 The Length value is 4. 645 Payload 647 The payload is null. 649 4.11.3. DeviceID Message 651 Expires March, 2003 [Page 12]^L 652 When this message will be sent: 654 This message MUST be sent by both PaC and PAA over an TLS 655 connection right after a TLS handshake is finished. 657 Meaning of this message: 659 When a PaC or a PAA receives this message, it checks whether the 660 Device Identifier contained in the message is the same as that is 661 included in the MAC and/or IP header(s) encapsulating this message. 662 If those two Device Identifiers are different, the receiver MUST 663 return an Error message with Subtype "InvalidDeviceID" and 664 immediately terminate the TLS session and the transport connection. 666 Structure of this message: 668 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | Type | Subtype | Length | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | | 673 ~ Device Identifier ~ 674 | | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 Type 679 Type value Type name 681 0x03 DeviceID 683 Subtype 685 Subtype value Subtype name 687 0x01 IPAddress 688 0x02 IPAndMACAddresses 690 IPAddress 692 This Subtype is used when the sender has no MAC address 693 associated with the transport connection. 695 IPAndMACAddresses 697 This Subtype is used when the sender has a MAC address 698 associated with the transport connection. 700 Length 702 Variable (8, 16, 20 or 28). 704 Payload 706 Expires March, 2003 [Page 13]^L 707 When the Subtype value is 0x01 (IPAddress), either IPv4 or IPv6 708 address is included depending on whether the transport connection 709 is carried over IPv4 or IPv6, respectively. When the Subtype 710 value is 0x02 (IPAndMACAddresses), either IPv4 or IPv6 address is 711 included depending on whether the transport connection is carried 712 over IPv4 or IPv6, respectively, immediately followed by an IEEE 713 EUI-64 address [EUI64]. 715 4.11.4. AuthInfo Message 717 When this message will be sent: 719 This message MUST be sent during Non-TLS Full Authentication. This 720 message MAY be sent during TLS Full Authentication. When this 721 message is sent, it MUST be sent right after DeviceID message 722 exchange. Multiple rounds of AuthInfo message exchange can occur 723 until Success or Failure message is sent by the PAA. 725 Meaning of this message: 727 The contents and processing rules of the payload depends on the 728 type of the authentication protocol. 730 Structure of this message: 732 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | Type | Subtype | Length | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | | 737 ~ Authentication Protocol Message ~ 738 | | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 Type 743 Type value Type name 745 0x04 AuthInfo 747 Subtype 749 Subtype value Subtype name 751 0x01 EAP 753 Length 755 Variable. 757 Payload 759 The contents depends on Subtype. If Subtype is 0x01 (EAP), an 761 Expires March, 2003 [Page 14]^L 762 EAP PDU [EAP] is included. 764 4.11.5. Success Message 766 When this message will be sent: 768 This message is sent by a PAA when a PaC is finally authenticated. 770 Meaning of this message: 772 This message means that the PaC that receives this message is 773 finally authenticated and the device associated with the Device 774 Identifier of the PaC is authorized for network access. 776 Structure of this message: 778 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Type | Subtype | Length | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 Type 785 Type value Type name 787 0x05 Success 789 Subtype 791 Subtype value Subtype name 793 0x01 NothingToDo 794 0x02 DoAHP 796 NothingToDo 798 This Subtype is used when there is no further processing 799 required for the PaC device to be fully authorized for network 800 access. 802 DoAHP 804 This Subtype is used when AHP is required between the PaC and 805 PAA. The TLS connection and the transport connection MUST 806 remain open as long as the PaC continues to be authorized for 807 network access. 809 Length 811 The Length value is 4. 813 Payload 815 The payload is null. 817 Expires March, 2003 [Page 15]^L 818 4.11.6. Failure Message 820 When this message will be sent: 822 This message is sent by a PAA when it finally fails to authenticate 823 a PaC. 825 Meaning of this message: 827 This message means that authentication for the PaC that receives 828 this message finally is not successful. When this message is sent, 829 the PAA MUST immediately terminate the TLS connection and the 830 transport connection. 832 Structure of this message: 834 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Type | Subtype | Length | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 Type 841 Type value Type name 843 0x06 Failure 845 Subtype 847 Subtype value Subtype name 849 0x00 NoSubtype 851 Length 853 The Length value is 4. 855 Payload 857 The payload is null. 859 4.11.7. Error Message 861 When this message will be sent: 863 This message is sent by a PAA or a PaC when it detects an error 864 except for authentication failure. This message can occur at any 865 time during PANA message exchange over a TLS connection. 867 Meaning of this message: 869 This message means that the sender detected an error except for 870 authentication failure. The Subtype indicates the reason of the 871 error. When this message is sent, the PAA MUST immediately 872 terminate the TLS connection and the transport connection. 874 Expires March, 2003 [Page 16]^L 875 When the receiver of this message finds an error for this message, 876 it MUST NOT return an Error message. 878 Structure of this message: 880 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Type | Subtype | Length | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 Type 887 Type value Type name 889 0x07 Error 891 Subtype 893 Subtype value Subtype name 895 0x01 InvalidDeviceID 896 0x02 UnexpectedMessageType 897 0x03 UnsupportedMessageType 898 0x04 UnsupportedMessageSubtype 899 0x05 InvalidMessageLength 900 0x06 InvalidPayloadContents 901 0x07 HeartbeatResponseTimeout 903 InvalidDeviceID 905 This Subtype is used when an invalid Device Identifier is 906 detected in a DeviceID message sent from the peer. 908 UnexpectedMessageType 910 This Subtype is used when a message is received with a Type 911 value that is supported by the node but the type is different 912 from that is expected at this specific protocol phase. 914 UnsupportedMessageType 916 This Subtype is used when a message is received with a Type 917 value that is not supported. 919 UnsupportedMessageSubType 921 This Subtype is used when a message is received with an 922 appropriate Type value but with a Subtype value that is not 923 supported. 925 InvalidMessageLength 927 This Subtype is used when inconsistency is detected between the 928 value of the Length field and the actual message length. 930 InvalidPayloadContents 932 Expires March, 2003 [Page 17]^L 933 This Subtype is used when the payload cannot be decoded based 934 on the expected format defined for the specified message Type 935 and Subtype. 937 HeartbeatResponseTimeout 939 This Subtype is used when the Heartbeat/Response timer for the 940 PaC expires. 942 Length 944 The Length value is 4. 946 Payload 948 The payload is null. 950 4.11.8. Heartbeat Message 952 When this message will be sent: 954 This message will be exchanged between a PaC to a PAA after a 955 Success message is sent by the PAA with a Subtype value 0x03 956 (DoAHP). The PAA sends a Heartbeat/Request message whenever it 957 wants to check whether the PaC is active or not, and the PaC is 958 requested to send Heartbeat/Response message back to the PAA in 959 response to the Heartbeat/Request. Heartbeat/Request messages MAY 960 be sent periodically. 962 Meaning of this message: 964 If the PAA that sent a Heartbeat/Request message to a PaC does not 965 receive a Heartbeat/Response from the PaC for a Heartbeat/Response 966 timeout period, the PAA MUST return an Error message with the 967 Subtype "HeartbeatResponseTimeout" and immediately terminate the 968 TLS connection and the transport connection. 970 Structure of this message: 972 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Type | Subtype | Length | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 Type 979 Type value Type name 981 0x08 Heartbeat 983 Subtype 985 Subtype value Subtype name 987 0x01 Request 989 Expires March, 2003 [Page 18]^L 990 0x02 Response 992 Length 994 The Length value is 4. 996 Payload 998 The payload is null. 1000 5. Protocol Parameters 1002 PortNumber 1004 The destination port number to be used for the messages defined in 1005 this document. The same PortNumber is used for UDP, TCP and SCTP. 1006 The value of the PortNumber is TBD. 1008 DefaultHeartbeatTimeout 1010 The default timeout value for Heartbeat/Response message. The 1011 value of DefaultHeartbeatTimeout is 5 seconds. 1013 All-PAA-Nodes 1015 A link-local multicast address used for sending PAADiscover 1016 messages. In the case of IPv4, All-PAA-Nodes is the same as "all- 1017 hosts" group (224.0.0.1). In the case of IPv6, All-PAA-Nodes is a 1018 link-local scoped multicast address to be assigned by IANA. 1020 6. Security Consideration 1022 Potential security threats for PANA over TLS are discussed in this 1023 section. 1025 6.1 Security on PAA Discovery 1027 Since PAADiscover and AuthRequest messages are not authenticated, it 1028 is possible for an attacker to send those messages with bogus 1029 information. 1031 The PAA that receives a bogus PAADiscover message will respond with a 1032 AuthRequest message. Since sending an AuthRequest message does not 1033 involve in any cryptographic computation or create any state at PAA, 1034 there is little impact on PAA for sending AuthRequest messages. 1036 If the PAADiscover message has a bogus source address, then a PaC 1037 that is not the originator of the PAA Discover message may receive an 1038 AuthRequest message, which may trigger Full Authentication or Fast 1039 Authentication. To reduce the impact of such a false authentication 1040 trigger, a PAA MAY have a policy for not accepting a new transport 1041 connection from a PaC device that has been authorized for network 1042 access until re-authentication becomes necessary for the PaC or that 1043 attempts to establish transport connections at a rate higher than the 1045 Expires March, 2003 [Page 19]^L 1046 threshold value. 1048 6.2 Security on Transport Connection for TLS 1050 When TCP is used for the TLS transport, it is vulnerable to a blind 1051 masquerade attack (i.e., TCP SYN attack), which could let PAAs spend 1052 memory resources for creating states for TCP connections. SCTP does 1053 not have such vulnerability due to the cookie-based four-way 1054 handshake mechanism. 1056 Since transport protocol headers that envelop TLS PDUs are not 1057 protected, the headers are vulnerable to deliberate integrity 1058 attacks, which may incur data corruption for the transport protocol 1059 payload (blind attack is not possible). This kind of attacks are 1060 always detected by TLS anyway. 1062 6.3 Security on TLS Handshake 1064 The same security consideration as described in Appendix F of [TLS] 1065 is applied to this part. Since this protocol mandates the use of a 1066 server certificate for Full Authentication, man-in-the-middle attacks 1067 against contents carried over TLS connections are protected by TLS. 1069 However, TLS handshake itself does not protect man-in-the-middle 1070 attacks against transport connections by spoofing MAC/IP address, 1071 unless client and server certificates are used for TLS handshake and 1072 each certificate is associated with either the IP address used for 1073 the transport connection or a DNS entry that is mapped to the 1074 transport IP address via secure DNS. DeviceID message exchange is 1075 used for protection against MAC/IP address spoofing (see next 1076 section). 1078 6.4 Security on PANA Message Exchange over TLS Connection 1080 Man-in-the-middle attacks against transport connections by spoofing 1081 MAC/IP address is prevented by using protected DeviceId message 1082 exchange over TLS. 1084 EAP or other authentication protocol exchange encapsulated in 1085 AuthInfo messages are cryptographically protected by TLS. All EAP 1086 messages including EAP-Response/Identity, EAP-Success and EAP-Failure 1087 messages can be encrypted and/or integrity protected. If the 1088 contents of EAP messages processed at a PAA need to be protected from 1089 being read in cleartext by the PAA, an appropriate EAP mechanism that 1090 supports EAP payload protection (i.e., EAP-SRP, EAP-TLS, EAP-TTLS, 1091 etc.) SHOULD be used. 1093 PANA Success/Failure and Heartbeat messages are also 1094 cryptographically protected by TLS. 1096 However, deliberate integrity attacks are possible at transport layer 1097 for these messages carried over TLS, as described in section 1098 "Security on Transport Connection for TLS". 1100 Expires March, 2003 [Page 20]^L 1101 7. Possible Future Direction 1103 This section describes a possible future direction considering the 1104 ongoing work on EAP. 1106 There are several EAP methods that use TLS for securing the payload 1107 of EAP messages. When those EAP methods are used, it might be 1108 possible to carry some of those messages in cleartext without 1109 compromising security at all. However, this requires a work in the 1110 EAP WG on security analysis as well as appropriate state machine 1111 definitions to make sure that only securing EAP payload is enough. 1113 Once it is proven that only securing EAP payload is sufficient or the 1114 EAP specification is enhanced to have a method to protect both EAP 1115 header and payload, the PANA over TLS protocol will define an 1116 optional method that allows carrying AuthInfo messages without 1117 protection while other messages are still protected in order to 1118 strike a better balance between the required level of security and 1119 processing overhead. 1121 Note that whatever EAP-based protection mechanism is applied to EAP 1122 header and/or payload, AuthInfo messages that carry EAP messages 1123 should be at least integrity protected if the PAA acts as a pass- 1124 through EAP authenticator so that an attacker cannot propagate 1125 "integrity broken" EAP messages all the way to the authentication 1126 server. If those messages are integrity protected by the PANA over 1127 TLS protocol, the PAA can immediately reject them before injecting 1128 into the backend authentication infrastructure. 1130 8. Acknowledgments 1132 The authors would like to thank Paal Engelstad for discussing on 1133 Device Identifier protection. 1135 9. References 1137 [DHCPAUTH] R. Droms, et. al., "Authentication for DHCP Messages", 1138 RFC 3118, June 2001. 1140 [EAP] L. Blunk, et. al., "PPP Extensible Authentication Protocol 1141 (EAP)", RFC 2284, March 1998. 1143 [EAPBIS] L. Blunk, et. al., "PPP Extensible Authentication Protocol 1144 (EAP)", Internet-Draft, draft-ietf-pppext-rfc2284bis-06.txt, 1145 Work in Progress, September 2002. 1147 [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) 1148 Registration Authority", 1149 http://standards.ieee.org/db/oui/tutorials/EUI64.html, March 1997. 1151 [IKE] D. Harkins, et al., "The Internet Key Exchange (IKE)", RFC 2409, 1152 November 1998. 1154 [Keywords] S. Bradner, "Key words for use in RFCs to Indicate 1156 Expires March, 2003 [Page 21]^L 1157 Requirement Levels", BCP 14, RFC 2119, March 1997. 1159 [PANAREQ] A. Yegin, et al., "Protocol for Carrying Authentication for 1160 Network Access (PANA) Requirements and Terminology", Internet-Draft, 1161 Work in Progress, June 2002. 1163 [PANAUSAGE] Y. Ohba, et al., "Problem Space and Usage Scenarios for 1164 PANA", Internet-Draft, Work in Progress, June 2002. 1166 [PIC] Y. Sheffer, et al., "PIC, A Pre-IKE Credential Provisioning 1167 Protocol", Internet-Draft, Work in Progress, February 2001. 1169 [TLS] T. Dierks, et al., "The TLS Protocol Version 1.0", RFC 2246, 1170 January 1999. 1172 10. Authors' Information 1174 Yoshihiro Ohba 1175 Toshiba America Research, Inc. 1176 P.O. Box 136 1177 Convent Station, NJ 07961-0136 1178 USA 1179 Phone: +1 973 829 5174 1180 Email: yohba@tari.toshiba.com 1182 Shinichi Baba 1183 Toshiba America Research, Inc. 1184 P.O. Box 136 1185 Convent Station, NJ 07961-0136 1186 USA 1187 Phone: +1 973 829 4759 1188 Email: sbaba@tari.toshiba.com 1190 Subir Das 1191 MCC 1D210R, Telcordia Technologies 1192 445 South Street, Morristown, NJ 07960 1193 Phone: +1 973 829 4959 1194 email: subir@research.telcordia.com 1196 Expires March, 2003 [Page 22]^L