Network Working Group J. Salowey Internet-Draft S. Thomson Expires: September 5, 2006 F. Wu V. Yarlagadda H. Zhou Cisco Systems March 4, 2006 Network Access Control Protocol (NACP) draft-thomson-nacp-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 5, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Network Access Control Protocol (NACP) is a protocol used to encapsulate EAP (Extensible Authentication Protocol) messages in a UDP (User Datagram Protocol) transport between an authenticator and peer. Salowey, et al. Expires September 5, 2006 [Page 1] Internet-Draft NACP March 2006 Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Salowey, et al. Expires September 5, 2006 [Page 2] Internet-Draft NACP March 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Message Contents . . . . . . . . . . . . . . . . . . . . . 4 2.2.1. Message Header . . . . . . . . . . . . . . . . . . . . 4 2.2.2. Message Payload . . . . . . . . . . . . . . . . . . . 5 2.3. Association . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Sequencing and Retransmission . . . . . . . . . . . . . . 6 2.5. Error handling . . . . . . . . . . . . . . . . . . . . . . 6 2.5.1. Invalid Version . . . . . . . . . . . . . . . . . . . 7 2.5.2. Invalid Association . . . . . . . . . . . . . . . . . 7 2.5.3. Message ID . . . . . . . . . . . . . . . . . . . . . . 7 2.5.4. Cookie TLV . . . . . . . . . . . . . . . . . . . . . . 7 2.5.5. Other . . . . . . . . . . . . . . . . . . . . . . . . 8 2.6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8 2.7. Transport Protocol . . . . . . . . . . . . . . . . . . . . 8 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Hello Message . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Validate Message . . . . . . . . . . . . . . . . . . . . . 9 3.3. Result Message . . . . . . . . . . . . . . . . . . . . . . 9 3.4. NAK message . . . . . . . . . . . . . . . . . . . . . . . 10 3.5. Example Operation . . . . . . . . . . . . . . . . . . . . 10 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Payload Format . . . . . . . . . . . . . . . . . . . . . . 13 4.2.1. General TLV format . . . . . . . . . . . . . . . . . . 13 4.2.2. Association ID TLV . . . . . . . . . . . . . . . . . . 14 4.2.3. EAP Payload TLV . . . . . . . . . . . . . . . . . . . 15 4.2.4. Cookie TLV . . . . . . . . . . . . . . . . . . . . . . 16 4.2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6.1. Blind Denial of Service Attacks . . . . . . . . . . . . . 18 6.2. On-path Attacks . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Salowey, et al. Expires September 5, 2006 [Page 3] Internet-Draft NACP March 2006 1. Introduction EAP [RFC3748] is a protocol used to communicate authentication and other information between an authenticator and peer for the purposes of enforcing access control at a particular device in the network. EAP has been defined to run over multiple L2 transports including wired and wireless LANs (802.1x)[[802.1X] and PPP[RFC1661]. This document specifies the Network Access Control Protocol (NACP), a protocol that encapsulates EAP messages in a UDP transport between an authenticator and peer. The authenticator and peer may be one or more L3 hops away from each other. 1.1. Terminology peer: End-system device that responds to EAP messages from authenticator authenticator: Network access device that initiates the EAP exchange association: A NACP connection between authenticator and peer. 2. Protocol Overview 2.1. Messages There are four NACP messages: o Hello message: Used to set up an association between authenticator and peer o Validate message: Used to transport EAP payloads between an authenticator and peer, with exception of EAP Success and EAP Failure payloads o Result message: Used to transport EAP Success and EAP failure payloads between authenticator and peer o NAK message: Used for NACP version negotiation 2.2. Message Contents 2.2.1. Message Header The NACP header contains the following fields (see Section 4 for the message format details): Salowey, et al. Expires September 5, 2006 [Page 4] Internet-Draft NACP March 2006 o Version of protocol in use. This specification of the protocol is version 1. o Message operation code (opCode)i.e. Hello, Validate, Result or NAK message o Flags indicating whether this message is a request or response o Length of payload o Message identifier (Message ID) for use in sequencing and retransmissions o Association identifier (Association ID) for uniquely identifying an NACP connection between a peer and authenticator. 2.2.2. Message Payload The following Type-Length-Value (TLV) tuples may be present in the NACP payload depending on the message type: o Association ID TLV. Communicates value of initial association ID between authenticator and peer o EAP Payload TLV. Used to encapsulate EAP messages between authenticator and peer o Cookie TLV. Used to protect peer from a blind resource consumption attack. 2.3. Association The authenticator establishes a NACP association for the purposes of authenticating and authorizing a peer using the EAP protocol. At a minimum, an association must be maintained on the authenticator and peer for the duration of the Hello-Validate-Result sequence to ensure that the EAP message exchange completes. An association should be maintained for a longer period of time where it is expected that the association will be used for other purposes e.g. periodic EAP re- authentication purposes. In such cases, the association is terminated based on an idle time-out or other event on the peer and authenticator. An association is uniquely identified on the authenticator by the peer's IP address and an identifier that is chosen to be unique on the authenticator. Similarly, an association is uniquely identified on the peer by the authenticator's IP address and an identifier that is chosen to be unique on the peer. The association identifier used Salowey, et al. Expires September 5, 2006 [Page 5] Internet-Draft NACP March 2006 on the peer and authenticator MUST be a random number greater than zero to protect against blind attacks and delayed packets. When the authenticator sends a message, it uses the peer's association identifier in the Association ID field; when the peer sends a message it uses the authenticator's association identifier in the Association ID field. The initial values of the Association IDs are exchanged in the Association ID TLV in the Hello payload. 2.4. Sequencing and Retransmission NACP is a request-response protocol. In any particular message exchange, one party acts as the initiator (sends a NACP request) and the other party acts as the responder (sends a NACP response message). In version 1 of the NACP protocol, the authenticator is always the initiator and the peer always the responder. The initiator sets the Message ID in the header to any value (such as zero) in the first message of the NACP association, and increases the Message ID by one for each new request using serial number arithmetic. Retransmissions do not increment the Message ID. The responder sets the message ID in the response to the value of the message ID in the request. The initiator is always responsible for retransmissions. The responder only retransmits a response on seeing a retransmitted request; it does not otherwise process the retransmitted request. The retransmitted requests/responses are exact duplicates of previous requests/responses. The initiator must not send a new request until it receives a response to the previous one. Packets with out-of-sequence Message IDs are considered invalid packets and are discarded. The initiator must retransmit after a configurable interval until either it gets a valid response, or decides after a configurable number of attempts that the NACP association has failed. (Since the retransmission algorithm is implementation-dependent, it is not defined here.) 2.5. Error handling A message is only accepted if all the following holds true: o Message version field = 1. o Association ID must match a current association Salowey, et al. Expires September 5, 2006 [Page 6] Internet-Draft NACP March 2006 o All messages received by peer have R bit in flag set to zero o All responses received by authenticator have R bit in flag set to one. o Message opCode is valid o Message length equals size of payload o Message ID must match the expected sequence number o The payload contains only those TLVs expected given the value of the opCode (see Section 4) o All TLVs within the payload are well-formed. Also, TLVs marked as mandatory are recognized. Processing of an invalid message is as follows: 2.5.1. Invalid Version If a responder receives a request with a message version that is higher than the version it supports, the responder MUST send a response with an opcode set to NAK, and with the version number field set to the highest version it can support. The responder does not further process the received packet. If the responder sends a version different from the version sent by the initiator, the packet will be silently discarded, if the opcode is not set to NAK. 2.5.2. Invalid Association The Association ID must match a current association, except in the first Hello request from the authenticator to the peer where the Association ID is set to zero. If the Association ID is invalid, the receiver silently discards the packet. 2.5.3. Message ID If the Message ID does not conform to the rules in the sequencing and retransmission section, the packet is discarded. 2.5.4. Cookie TLV The cookie TLV is sent by the peer in a Hello response. The Salowey, et al. Expires September 5, 2006 [Page 7] Internet-Draft NACP March 2006 authenticator includes the cookie TLV in the first Validate message of the NACP association. If the cookie sent by the peer is not the one received, the peer discards the packet. 2.5.5. Other If any of the other conditions are not met, the packet is also discarded. 2.6. Fragmentation NACP does not provide support for fragmentation. The EAP method may support fragmentation and/or the IP layer may be used to support fragmentation where the link-layer MTU requires it. 2.7. Transport Protocol NACP uses UDP as the transport protocol with port number TBD. All messages are unicast. 3. Protocol Operation 3.1. Hello Message PEER AUTHENTICATOR <-Hello(MsgID=x,AssocnID=0)[AssocnID=N]--------------------- -Hello(MsgID=x,AssocnID=N)[AssocnID=M][Cookie-TLV]--------> When a new NACP association is initiated, the authenticator sends a Hello message to the peer. The Hello message contains the Association ID TLV. The authenticator chooses a random non-zero 32-bit number for the Association ID that is unique across all current associations. The peer responds to the Hello message with an Association ID TLV of its own in the payload. The peer chooses a random 32-bit number to uniquely identify its end of the association and sends it in the Association ID TLV in the Hello payload. The peer also sends a cookie in the Cookie TLV. The authenticator must include this TLV in the subsequent request message so that the peer can verify that the authenticator is the one that initiated the NACP conversation. The peer does not maintain state about the association with the authenticator until the next request message is received with a valid Cookie TLV. Salowey, et al. Expires September 5, 2006 [Page 8] Internet-Draft NACP March 2006 3.2. Validate Message PEER AUTHENTICATOR <-Validate(MsgID=x+1,AssocnID=M)[EAP Payload][Cookie TLV]------- --Validate(MsgID=x+1,AssocnID=N)[EAP Payload]------------------> : : : <-Validate(MsgID=x+y,Assocn ID=M)[EAP Payload]---------------- --Validate(MsgID=x+y,AssocnID=N)[EAP Payload]------------------> Once an association is set up using the Hello exchange, the authenticator uses EAP to request credentials from the peer as defined in [RFC3748 [RFC3748]].The authenticator encapsulates EAP request and response messages (but not Success and Failure messages) in Validate packets. The authenticator includes the Cookie TLV that it received in the Hello response in the first Validate request. The authenticator does not otherwise process the cookie. Authenticator does not include the Cookie TLV in any of the subsequent Validate messages. The peer responds to a Validate request following normal processing rules. If this is the first Validate request in the NACP association, the peer also validates the cookie before creating association state. The Validate message exchange lasts for as long as the EAP Layer requires, and typically ends in the sending of an EAP Success/Failure using the Result message described below. 3.3. Result Message PEER AUTHENTICATOR <-Result(MsgID=x+y+1,AssocnID=M)[EAP Success/Failure] ---- --Result(MsgID=x+y+1,AssocnID=N)--------------------------> The authenticator encapsulates an EAP Success or Failure message in the NACP Result message. Note that where the authenticator is acting as EAP pass-through, it needs to look into the EAP header to determine when an EAP Success/Reject is being sent. The peer responds to a Result request with a Result response. A Result response carries no payload. Salowey, et al. Expires September 5, 2006 [Page 9] Internet-Draft NACP March 2006 On receiving a response to the Result message, the authenticator validates the Result packet according to NACP processing rules described above. No further processing is done since the response is empty. 3.4. NAK message If the peer receives a request with a message version that is higher than the version it supports, the peer MUST send a response with an opcode set to NAK, and with the version number field set to the highest version it can support. The peer does not further process the packet. 3.5. Example Operation When an association is established, the following flow takes place: PEER AUTHENTICATOR <-Hello(MsgID=x,AssocnID=0)[AssocnID=N]--------------------- --Hello(MsgID=x,AssocnID=N)[AssocnID=M][Cookie-TLV]--------> <-Validate(MsgID=x+1,AssocnID=M)[EAP Identity][Cookie TLV]---- --Validate(MsgID=x+1,AssocnID=N)[EAP Identity]--------------> <-Validate(MsgID=x+2,AssocnID=M)[EAP method]---------------- --Validate(MsgID=x+2,AssocnID=N)[EAP method]---------------> : : : <-Validate(MsgID=x+y,AssocnID=M)[EAP method]---------------- --Validate(MsgID=x+y,AssocnID=N)[EAP method]------------------> <-Result(MsgID=x+y+1,AssocnID=M)[EAP Success] ------------ --Result(MsgID=x+y+1,AssocnID=N)--------------------------> Once an association exists, the following flow takes place e.g. on EAP re-authentication: Salowey, et al. Expires September 5, 2006 [Page 10] Internet-Draft NACP March 2006 PEER AUTHENTICATOR <-Validate(MsgID=x+y+2,AssocnID=M)[EAP Identity]-------------- --Validate(MsgID=x+y+2,AssocnID=N)[EAP Identity]-------------> <-Validate(MsgID=x+y+3,AssocnID=M)[EAP method]---------------- --Validate(MsgID=x+y+3,AssocnID=N)[EAP method]------- ------> : : : <-Validate(MsgID=x+z,AssocnID=M)[EAP method]---------------- --Validate(MsgID=x+z,AssocnID=N)[EAP method]---------------> <-Result(MsgID=x+z+1,AssocnID=M)[EAP Success] ------------ --Result(MsgID=x+z+1,AssocnID=N)--------------------------> 4. Message Format All messages are transmitted in network byte order. The message format has the following structure: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Message Header | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / / Message Payload / / (Zero or more TLVs) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The subsections below describes the format of the header and payload. 4.1. Header Format Salowey, et al. Expires September 5, 2006 [Page 11] Internet-Draft NACP March 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Vers |Opcode | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags 8-bit field indicating options 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |M| Reserved | +-+-+-+-+-+-+-+-+ Response Flag (R). Set to 1 when message is a response to a request (same message ID). R must be zero in all request messages. Reserved Flags: Reserved. Must be zero. MUST be cleared on sending and ignored on receipt. Version: 4-bit field indicating the version of this protocol. This specification = 1 OpCode 4 bit field indicating NACP message type NAK = 1 (response only) Hello= 2 Validate = 3 Result = 4 Length Length of NACP payload in octets excluding header Message ID Used to ensure ordered delivery and detect retransmissions. Association ID Uniquely identifies association in authenticator and peer. Salowey, et al. Expires September 5, 2006 [Page 12] Internet-Draft NACP March 2006 4.2. Payload Format The payload consists of zero or more type-length-value 3-tuples (TLVs). Note: TLVs may not always start on a 4-byte boundary. 4.2.1. General TLV format The general TLV format is shown below. Salowey, et al. Expires September 5, 2006 [Page 13] Internet-Draft NACP March 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags 8-bit field indicating options 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |M| Reserved | +-+-+-+-+-+-+-+-+ Mandatory Flag: When set to one, the TLV Type is mandatory to support. If the Type is not recognized, the packet is discarded. When the M flag is set to zero, the TLV is optional. If an optional TLV Type is not recognized, it is ignored and processing of the packet continues. Reserved: Must be zero. Cleared on sending and ignored on receipt. Type 8-bit field indicating type of Value field. 1= Association ID TLV 2 = EAP Payload TLV 3 = Cookie TLV Length 16-bit field indicating length of Value field in octets Value Value field depends on Type. 4.2.2. Association ID TLV Salowey, et al. Expires September 5, 2006 [Page 14] Internet-Draft NACP March 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags Mandatory Flag: Set to 1 Type 1 Length 4 Association ID Locally selected non-zero 32-bit random number that uniquely identifies an association on authenticator and peer. The authenticator uses this TLV in a Hello request to indicate to the peer what association ID to use in all packets the peer sends to the authenticator (including the Hello response). The peer uses this TLV in a Hello response to indicate to the authenticator what association ID to use in subsequent packets the authenticator sends to the peer. 4.2.3. EAP Payload TLV Salowey, et al. Expires September 5, 2006 [Page 15] Internet-Draft NACP March 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Payload / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags Mandatory Flag: Set to 1 Type 2 Length Length of EAP Payload in octets EAP Payload EAP Packet An EAP Payload TLV is used in Validate messages to carry EAP Requests and Responses, and in the Result message (Request only) to send an EAP Success or Failure message. 4.2.4. Cookie TLV Salowey, et al. Expires September 5, 2006 [Page 16] Internet-Draft NACP March 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cookie / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags Mandatory Flag: Set to 1 Type 3 Length Length of Cookie in octets Cookie Cookie algorithm is implementation-dependent. It consists of information sufficient to establish the association with the authenticator after the first Validate request us received and is protected by a secret known only to the peer. The Cookie TLV is used by the peer to protect itself against a DOS attack from a device that is blindly launching spurious Hello requests. The peer must include the cookie TLV in a Hello response. The authenticator must return the cookie TLV in the first Validate request of the association only. The peer does not establish state until the cookie in the first Validate message has been received and validated. The cookie algorithm is not defined in this specification as it is not needed for interoperability. 4.2.5. Summary This section summarizes the TLVs that are valid for each message. o NAK Response: None o Hello Request: Association ID TLV o Hello Response: Association ID TLV, Cookie TLV o Validate Request: EAP Payload TLV, Cookie TLV (first Validate only) o Validate Response: EAP Payload TLV Salowey, et al. Expires September 5, 2006 [Page 17] Internet-Draft NACP March 2006 o Result Request: EAP Payload TLV o Result Response: None 5. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to NACP NACP uses a UDP port number that needs to be assigned by IANA. The following namespaces in NACP require registration: OpCodes, TLV Types. 6. Security Considerations We consider NACP security vulnerabilities in this section. 6.1. Blind Denial of Service Attacks An attacker may carry out a number of blind denial of service attacks on a peer or authenticator using NACP: 1. An attacker may attempt to mount a denial of service attack on a peer or authenticator by injecting NACP packets into an existing association 2. An attacker may attempt to mount a denial of service attack on the peer by spoofing Hello messages The Association ID is a random number and can be used to protect an association from being compromised by a blind packet injection attack. The Cookie TLV protects a peer against fraudulent authenticators spoofing Hello messages with the intent of consuming resources on the peer and denying legitimate authenticators from communicating with the peer. 6.2. On-path Attacks An attacker that has access to NACP packets may eavesdrop on an association, or launch an attack on an association by inserting, deleting, modifying and replaying packets causing an authenticator or peer to discard or misinterpret packets and compromise the association. Salowey, et al. Expires September 5, 2006 [Page 18] Internet-Draft NACP March 2006 NACP does not provide protection against these forms of attacks. In particular, NACP does not protect the EAP message exchange where eavesdropping and man-in-the-middle attacks are a significant risk. It is therefore the responsibility of the network operators and end users to choose the proper EAP method to protect their particular environment. The contents of EAP messages transported inside NACP must be protected using an EAP method that meets the requirements for securing the transfer of authentication and other information for the purposes of network access control. Security considerations for EAP methods are discussed in RFC3748 [RFC3748]. If breach of confidentiality and deliberate attacks on the integrity of the NACP protocol itself are a significant risk in certain deployment environments, NACP should be protected by a protocol that offers confidentiality and/or packet authentication, integrity and protection against replay e.g. IPSEC [RFC2401]. 7. Acknowledgements We acknowledge the contributions of Saul Adler, Eli Gelasco and Dany Rochefort. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [802.1X] IEEE, "Local and Metropolitan Area Networks:Port-based Network Access Control", 2004. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. Salowey, et al. Expires September 5, 2006 [Page 19] Internet-Draft NACP March 2006 Authors' Addresses Joseph Salowey Cisco Systems 2901 3rd Ave Seattke, WA 98121 U.S.A Email: jsalowey@cisco.com Susan Thomson Cisco Systems 499 Thornall Street, 8th floor Edison, NJ 08837 U.S.A Email: sethomso@cisco.com Fan Wu Cisco Systems 5400 Airport Boulevard Boulder, CO 80301 U.S.A. Email: wufan@cisco.com Venkateswara Rao Yarlagadda Cisco Systems No. 9 Brunton Road Bangalore, Karnataka India Email: yvrao@cisco.com Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield, OH 44286 U.S.A. Email: hzhou@cisco.com Salowey, et al. Expires September 5, 2006 [Page 20] Internet-Draft NACP March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Salowey, et al. Expires September 5, 2006 [Page 21]