Yoshi,
Thank you very much for addressing the comments.
My answers inline.
regards,
-Subir
Yoshihiro Ohba wrote:
> 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"
>
Subir> fine.
> 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.
>
Subir> That would be better.
>
> 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.
>
Subir> Agreed.
> 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.
>
Subir> Ok.
> [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."
>
Subir> Fine with me.
>
> 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.
>
Subir> Even better.
>
> 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.
>
Subir> Ok.
> "
>
> 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.
>
Subir> Much better.
> "
>
> 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.
>
> "
>
Subir> Good.
>
> 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.)
>
Subir> Fine with me. You may like to add "Authorization" after
authentication
since PANA session can be terminated if authorization fails but
authentication
succeeds.
> 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".
>
Subir> good.
> 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.
>
> "
>
Subir> The problem here is it is either request or answer. It can not be
both.
If answers arrive with frequent requests, then there is no loss of
connectivity.
Am I correct? Also you may delete "highly" here.
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".
>
Subir> Ok.
> 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.
>
Subir> fine.
> 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.
>
Subir> The question is when PaC will retransmit instead of discarding? This
race condition may continue for a while.
> 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.
>
> "
>
Subir> How about this:
"The PaC and PAA maintain two sequence numbers: one is for outgoing
request and the other one is for 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/.
>
Subir> ok.
>
> 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/.
>
Subir> ok.
>
> 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).
>
Subir> ok.
> + 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.
> "
>
Subir> good.
>
> 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.
>
Subir> ok.
> [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.
>
Subir> ok.
> 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.
> "
>
Subir> fine.
> 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.
>
Subir> Ok.
> ------
>
> Best Regards,
> Yoshihiro Ohba
>
> _______________________________________________
> Pana mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/pana
>
_______________________________________________
Pana mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pana
