One document matched: draft-thomson-nacp-02.txt
Differences from draft-thomson-nacp-01.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 02:48:05 |