Hi Subir and all,
Thank you very much for your review comments. The comments are
definitely useful to improve the quality of the draft.
Please see my response below.
-------------------------------------
Session Lifetime:
A duration that is associated with a PANA session. For an
established PANA session, the session lifetime is bound to the
lifetime of the current authorization given to the PaC. The
session lifetime can be updated[a1] by a new round of EAP
authentication before it expires.
[a1]Extended may be a better term here.
[YO] OK, s/updated/extended/.
Session Identifier:
This identifier is used to uniquely identify a PANA session on the
PaC and the PAA. It is included in PANA messages to bind the
message to a specific PANA session. This bidirectional identifier
is allocated by the PAA in the initial request message and freed
when the session terminates. The session identifier is assigned
by the PAA and is unique within the PAA [a2]during the lifetime of the
session.
[a2]May like to delete this part
[YO] We can delete "during the lifetime of the session"
Enforcement Point (EP):
A node on the access network where per-packet enforcement policies
(i.e., filters) are applied on the inbound and outbound traffic of
access devices. The EP and the PAA may be co-located. EPs should
prevent data traffic from and to any unauthorized client unless
it's either PANA or one of the other allowed traffic types (e.g.,
ARP, IPv6 neighbor discovery, DHCP, etc.). Detailed enforcement
policies may be specified in deployment-specific PANA
applicability documents.[a3]
[a3]Is it specified in a separate document. If so, pl. provide the
reference, otherwise delete this sentence.
[YO] There is an expired draft: draft-morand-pana-panaoverdsl-00.txt,
but we can simply remove the sentence to move forward.
o Access phase: After a successful authentication and authorization
the host[a4] gains access to the network and can send and receive IP[a5]
data traffic through the EP(s). At any time during this phase,
the PaC and PAA may optionally send PANA notification messages to
test liveness of the PANA session on the peer.
[a4]Other places ?access device? is used. A consistent terminology would be
better.
[YO] I agree, s/host/access node/.
[a5]Is this correct? Are DHCP, ND, ARP not IP data traffic?
[YO] ARP is definitely not IP. I am not sure if we can categorize
DHCP and ND as IP control or data traffic. I think we can remove
"data" here.
o Re-authentication phase: During the access phase, the PAA must
initiate re-authentication before the PANA session lifetime
expires. EAP is carried by PANA to perform authentication.[a6] This
phase may be optionally triggered by both the PaC and the PAA
without any respect to the session lifetime. [a7] The session moves to
this phase from the access phase, and returns back there upon
successful re-authentication.
[a6]Is it authentication or re-authentication?
[YO] It should be s/authentication/re-authentication, because this
paragraph is talking about re-authentication phase.
[a7]May consider revising this part.
[YO] I agree. Since authorization state remains during
re-authentication, re-authentication phase should be described as a
sub-phase of access phase. How about this?
"Re-authentication phase is a sub-phase of access phase. The
session moves to this sub-phase from the access phase when
re-authentication starts, and returns back there upon successful
re-authentication."
Cryptographic protection of messages between the PaC and PAA is
possible as soon as EAP in conjunction with the EAP method exports a
shared key. That shared key is used to create a PANA SA. The PANA
SA helps generate per-message authentication codes that provide
integrity protection and authentication.
Throughout the lifetime of a session, various problems found with the
incoming messages can generate an error request message (see
Section 5.8) sent in response.[a8]
[a8]other places ?answer? is used .. terminology problem..
[YO] I think we can simply remove the paragraph. I don't think we
need error handling overview in protocol overview section.
The PAA SHOULD limit the rate it processes incoming[a9]
PANA-Client-Initiation messages in order not to subject itself to
denial-of service (DoS) attacks. Details of rate limiting are
outside the scope of this specification.
[a9]May consider revising the sentence.
[YO] How about this?
"
The PAA SHOULD limit the rate it processes incoming
PANA-Client-Initiation messages to provide robustness against
denial-of service (DoS) attacks.
"
If the PAA wants to stay stateless in response to a
PANA-Client-Initiation message, it SHOULD NOT include an EAP-Payload
AVP in the initial PANA-Auth-Request message, and it SHOULD NOT re-
transmit the message on a timer. For this reason, the PaC MUST
retransmit the PANA-Client-Initiation message until it enters the
authentication and authorization phase by receiving the second
PANA-Auth-Request message (not a retransmission of the initial one)
from the PAA.[a10]
[a10]Not clear in particular, the last part of the sentence.
[YO] There is some leftover from previous revison that had handshake
phase which we don't have now. We can revise the sentence to:
"
For this reason, the PaC MUST retransmit the PANA-Client-Initiation
message until it receives the second PANA-Auth-Request message (not
a retransmission of the initial one) from the PAA.
"
PaC PAA Message(sequence number)[AVPs]
--------------------------------------------------------------------
-----> PANA-Client-Initiation(0)
<----- PANA-Auth-Request(x) // 'S' bit set
-----> PANA-Auth-Answer(x) // 'S' bit set
<----- PANA-Auth-Request(x+1)[Nonce, EAP]
-----> PANA-Auth-Answer(x+1)[Nonce] // No piggybacking EAP
-----> PANA-Auth-Request(y)[EAP]
<----- PANA-Auth-Answer(y)
<----- PANA-Auth-Request(x+2)[EAP]
-----> PANA-Auth-Answer(x+2)[EAP][a11]
<----- PANA-Auth-Request(x+3)[Result-Code, EAP, Key-Id,
Algorithm, Lifetime, AUTH]
// 'C' bit set
-----> PANA-Auth-Answer(x+3)[Key-Id, AUTH]
// 'C' bit set
Figure 1: Example sequence for the authentication and authorization
phase for a PaC-initiated session
[a11]Is this piggybacked EAP? It is not clear why EAP is not inlcuded
in PANA-Auth_Answer (y). Some texts explaning the piggybaked EAP will
be helpful
[YO] We can add "// Piggybacking EAP" here. To explain piggybacked EAP,
we can revise the Figure 1 caption as follows:
"
Figure 1: Example sequence for the authentication and
authorization phase for a PaC-initiated session ("Piggybacking
EAP" is the case in which an EAP AVP is carried in PAN.)
"
The last PANA-Auth-Request message MUST also carry an Algorithm AVP
if it is for the first derivation of keys in the session. The PANA
session MUST be deleted immediately after the last PANA-Auth message
exchange.[a12]
[a12]Is it really a PANA Session? This is happening during
authentication and authorization phase which is a part of a PANA
session. Also the definition of PANA should include authorization as a
cause to session termination.
[YO] Yes, it's a PANA session that is terminated
(s/deleted/terminated/ per your other comment.). With regard to
authorization as a cause to session termination, we can revise the
PANA Session definition in Section 2 to:
PANA Session:
A PANA session is established between the PANA Client (PaC) and
the PANA Authentication Agent (PAA), and terminates as a result
of an authentication or liveness test failure, a message
delivery failure after retransmissions reach maximum values or
session lifetime expiration, an explicit termination message or
any event that causes discontinuation of the access service. A
fixed session identifier is maintained throughout a session. A
session cannot be shared across multiple network interfaces.
("any event that causes discontinuation of the access service" was added.)
4.2. Access Phase
Once the authentication and authorization phase or the
re-authentication phase successfully completes,[a13] the PaC gains access
[a13]Is this true? Accordig to eralier definition or re-authenticatrion, it
happens during access phase.
[YO] You are right. We should remove "or the re-authentication phase".
to the network and can send and receive IP data traffic through the
EP(s) and the PANA session enters the access phase. In this phase,
PANA-Notification-Request and PANA-Notification-Answer messages with
'P' (Ping) bit set (ping request and ping answer messages,
respectively) can be used for testing the liveness of the PANA
session on the PANA peer. Both the PaC and the PAA are allowed to
send a ping request to the communicating peer whenever they need to
make sure the availability of the session on the peer and expect the
peer to return a ping answer message. The ping request and answer
messages MUST be protected with an AUTH AVP when a PANA SA is
available.
Implementations MUST limit the rate of performing this test. The PaC
and the PAA can handle rate limitation on their own, they do not have
to perform any coordination with each other. There is no negotiation
of timers for this purpose. Additionally, an implementation MAY
rate-limit processing of the incoming ping requests. It should be noted
that if a PAA or PaC which considers its connectivity lost after a
relatively small number of unresponsive pings coupled with a peer
that is aggressively rate-limiting the ping request and answer
messages, false-positives could result. [a14] Care should be taken when
rate-limiting ping request and answer messages to periodically
respond, and a PAA or PaC should not rely on ping request and answer
messages to quickly determine loss of connectivity.
[a14]Not clear. May consider revising the senetence.
[YO] How about this?
"
Therefore, a PAA or PaC should not rely on highly frequent ping
request and answer message exchanges to quickly determine loss of
connectivity.
"
4.3. Re-authentication Phase
The PANA session in the access phase can enter the re-authentication
phase to extend the current session lifetime by re-executing EAP.
Once the re-authentication phase successfully completes, the session
re-enters the access phase. Otherwise, the session is deleted.[a15]
[a15]Is it deleted or "terminated"?
[YO] It should be "terminated".
When the PaC wants to initiate re-authentication, it sends a
PANA-Notification-Request message with 'A' bit set (a re-
authentication request message) to the PAA. This message MUST
contain the session identifier assigned to the session being
re-authenticated. If the PAA already has an established PANA session
for the PaC with the matching session identifier, it MUST first
respond with a PANA-Notification-Answer message with 'A' bit set (a
re-authentication answer message), followed by a PANA-Auth-Request
message that starts a new EAP authentication. If the PAA cannot
identify the session, it MUST silently discard the message. The
first PANA-Auth-Request and PANA-Auth-Answer messages in the
re-authentication phase MUST have 'S' bit cleared [a16]and carry a Nonce
AVP.
[a16]Some places it says bit is not set and other places it is
cleared. Consistency would be good.
[YO] We shall use "cleared" throughout the document.
The PaC may receive a PANA-Auth-Request before receiving the answer
to its outstanding re-authentication request message. This condition
can arise due to packet re-ordering or a race condition between the
PaC and PAA when they both attempt to engage in re-authentication.
The PaC MUST keep discarding the received PANA-Auth-Requests until it
receives the answer to its request.[a17]
[a17]How will PAA know that PaC has not received it? Will PaC
retransmit PANA-Notification-Request?
[YO] Yes. The PAA will answer to the PNR.
5.2. Sequence Number and Retransmission
PANA uses sequence numbers to provide ordered and reliable delivery
of messages.
The PaC and PAA maintain two sequence numbers: the next one to be
used for a request it initiates and the next one it expects to see in
a request from the other end. [a18] These sequence numbers are 32-bit
[a18]Not clear. May cosnider revising it.
[YO] How about this?
"
The PaC and PAA maintain two sequence numbers: the one to be used
for the next outgoing request and the one it expects to see in the
next incoming request.
"
unsigned numbers. They are monotonically incremented by 1 as new
requests are generated and received, and wrapped to zero on the next
message after 2^32-1. Answers always contain the same sequence
number as the corresponding request. Retransmissions reuse the
sequence number contained in the original packet.
The initial sequence numbers (ISN) are randomly picked by the PaC and
PAA as they send their very first request messages except
PANA-Client-Initiation message that MUST be always 0.
When a request message is received, it is considered valid in terms
of sequence numbers if and only if its sequence number matches the
expected value. This check does not apply to the
PANA-Client-Initiation message and the initial PANA-Auth-Request
message.
When an answer message is received, it is considered valid in terms
of sequence numbers if and only if its sequence number matches that
of the currently outstanding request. A peer can only have one
outstanding request at a time.
PANA request messages are retransmitted based on a timer until a
response[a19] is received (in which case the retransmission timer is
[a19]Should be 'answer'
[YO] Yes, s/response/answer/.
stopped) or the number of retransmission reaches the maximum value
(in which case the PANA session MUST be deleted[a20] immediately).
[a20]Is it deleted or terminated ?
[YO] s/deleted/terminated/.
5.5. Message Validity Check
When a PANA message is received, the message is considered to be
invalid at least when one of the following conditions are not met:
o Each field in the message header contains a valid value including
sequence number, message length, message type, version number,
flags, session identifier, etc.
o The message type is one of the expected types in the current
state. Specifically the following messages are unexpected and
invalid:
* In the authentication and authorization phase and the
re-authentication phase:
+ PANA-Client-Initiation after completion of the initial
PANA-Auth-Request and PANA-Auth-Answer exchange.
+ Re-authentication request.[a21]
[a21]This seems incorrect since it is expected that re-authentication
request will apprear during re-authntication phase.
[YO] You are right. Re-auth request should be accepted at least in
re-authentication phase to deal with re-auth race condition (i.e.,
re-auth request and PAR cross each other).
+ The last PANA-Auth-Request as well as ping request before
completion of the initial PANA-Auth-Request and
PANA-Auth-Answer exchange.
+ The initial PANA-Auth-Request after a PaC receives a valid
non-initial PANA-Auth-Request.
+ PANA-Termination-Request.[a22]
[a22]Same as before.
[YO] You are right. Re-auth request should be accepted at least in
re-authentication phase to deal with another race condition (i.e., PTR
and re-auth request or PAR cross each other). Now I think it is
better to separate items for authentication and authorization phase
and re-authentication phase.
* In the access phase:
+ PANA-Auth-Request.[a23]
[a23]Same as before since PANA-Auth-Request may appear during re-authentication
phase.
[YO] Yes, PAR should be allowed for PAA-initiated re-auth. We should remove
this.
+ PANA-Client-Initiation.
* In the termination phase:
+ PANA-Client-Initiation.
+ All requests but PANA-Termination-Request.
[YO] So here is the new deny rule-set (including the resolution of
recent ping issue):
"
* In the authentication and authorization phase:
+ PANA-Client-Initiation after completion of the initial
PANA-Auth-Request and PANA-Auth-Answer exchange.
+ Re-authentication request.
+ The last PANA-Auth-Request as well as ping request before
completion of the initial PANA-Auth-Request and
PANA-Auth-Answer exchange.
+ The initial PANA-Auth-Request after a PaC receives a valid
non-initial PANA-Auth-Request.
+ PANA-Termination-Request.
* In the re-authentication phase:
+ PANA-Client-Initiation.
+ The initial PANA-Auth-Request.
* In the access phase:
+ PANA-Client-Initiation.
* In the termination phase:
+ PANA-Client-Initiation.
+ All requests but PANA-Termination-Request and ping request.
"
6.1. IP and UDP Headers
Any PANA message is unicast between the PaC and the PAA.
For any PANA message sent from the peer that has initiated the PANA
session, the UDP source port is set to any number and the destination
port is set to the assigned PANA port number (to be assigned by
IANA). For any PANA message sent from the other peer, the source
port is set to the assigned PANA port number (to be assigned by IANA)
and the destination port is copied from the source port of the last
received message. [a24]In case both the PaC and PAA initiates the session
(i.e., PANA-Client-Initiation and unsolicited PANA-Auth-Request
messages cross each other), then the PaC is identified as the
initiator.
[a24]What happens if PaC chooses a source port number that is used by PAA?
[YO] According to the rule, the PAA will change its source port number
to PANA port number once the initiator is determined to be the PaC.
[a25]8.4. Failed-AVP AVP
[a25]This AVP describes the vaule format while few others do not.
[YO] Because it is of type Grouped.
The Failed-AVP AVP (AVP Code 4) provides debugging information in
cases where a message is rejected or not fully processed due to
erroneous information in a specific AVP. The AVP data is of type
Grouped. The format of the Failed-AVP AVP using the ABNF grammar
defined in [RFC3588] for Grouped AVP is as follows.
<Failed-AVP> ::= < AVP Header: 4 >
1* {AVP}
In case of a failed grouped AVP, the Failed-AVP contains the whole
grouped AVP. In case of a failed AVP inside a grouped AVP, the
Failed-AVP contains the single offending AVP.
8.7. Nonce AVP
The Nonce AVP (AVP Code 7) carries a randomly chosen value that is
used in cryptographic key computations. The recommendations in
[RFC4086] apply with regard to generation of random values. The AVP
data is of type OctetString and it contains a randomly generated
value in opaque format. The data length MUST be between 8 and 256
octets inclusive.
The length of the nonces are determined based on the available
pseudo-random functions (PRFs) and the degree of trust placed into
the two PaC and the PAA to compute random values. The length of the
random value for the nonce is determined whether
1. The PaC and the PAA each are likely to be able to compute a
random nonce (according to [RFC4086]). The length of the nonce
has to be 1/2 the length of the PRF key [a26](e.g., 10 octets in the
case of HMAC-SHA1).
2. The PaC and the PAA each are not trusted with regard to the
computation of a random nonce (according to [RFC4086]). The
length of the nonce has to have the full length [a27]of the PRF key
(e.g., 20 octets in the case of HMAC-SHA1).
Furthermore, the strongest available PRF available for PANA has to be
considered in this computation. Currently, only a single PRF (namely
HMAC-SHA1) is available and therefore the maximum output length is 20
octets). The recommended maximum length of the nonce value is
therefore currently 20 octets.
[a26]Is it a MUST or SHOULD?
[a27]Same a s before.
[YO] The enumerated paragraphs are investigation. So we should not
use RFC2119 requirements language there. On the other hand, the next
paragraph should contain requirements language. How about this?
"
The maximum length of the nonce value in PANA Version 1 SHOULD be
therefore 20 octets.
"
8.8. Result-Code AVP
The Result-Code AVP (AVP Code 8) is of type Unsigned32 and indicates
whether an EAP authentication was completed successfully or whether
an error occurred. Result-Code AVP values are described in the
subsequent sections.
8.8.1. Authentication Results Codes
These result code values inform the PaC about the authentication and
authorization result. The authentication result and authorization
result can be different as described below, but only one result is
returned to the PaC. These codes are used with PANA-Auth-Request
message with 'C' bit set.
PANA_SUCCESS 0
Both authentication and authorization processes are successful.
PANA_AUTHENTICATION_REJECTED 1
Authentication has failed. When this error is returned, it is
assumed that authorization is automatically failed.
PANA_AUTHORIZATION_REJECTED [a28]2
The authorization process has failed. This error could occur when
authorization is rejected by a AAA server or rejected locally by a
PAA, even if the authentication procedure has succeeded.
[a28]How about Authentication-Success but Authorization_Failed? Is it useful?
[YO] I think PANA_AUTHORIZATION_REJECTED meant it.
------
Best Regards,
Yoshihiro Ohba
_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana
