Subject: [Pana] Preliminary pana-pana draft (13a)

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 19 Nov 2006 03:39:03 -0500

is available at:

http://www.panasec.org/docs/editing/pana-spec.html

(Now we get 17 pages reduction.)

Please do sanity check to make sure that all resolutions discussed in
IETF67 and over mailing list are reflected appropriately.  Diff from
revision 12 is also available.

As soon as sanity check is done, I will submit a new revision (13)
which is to be used for IETF last call.

Regards,
Yoshihiro Ohba

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 21 Nov 2006 17:29:53 +0200

Thank you Yoshi.

Let's set a timer. PANA WG members: Please review and register your feedback
by the end of Nov 28 (one week). 

Alper

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Sunday, November 19, 2006 10:39 AM
> To: [email-masked]
> Subject: [Pana] Preliminary pana-pana draft (13a)
> 
> is available at:
>

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 27 Nov 2006 19:02:12 -0500

Hi Yoshi, Alper,

I have some initial comments on pana-pana-13. I think the spec is much 
more simple now. Anyway, some minor comments below:

* Sec 2. Terminology for Session Identifier

   Minor clarification. Is there any description on what properties a
   session identifier should have ? i.e. Should it be global and eternally
   unique as described previously in pana-pana-12 ?

* Sec 4.6 Re-Authentication Phase, 2nd Paragraph, 5th sentence

   "Transmission of this error request is made optional
    in case this behavior is leveraged for ..."

    I'm not sure which error request the text is refering to.

* Sec 5.2 Sequence Number and Retransmission, 6th Paragraph, 1st sentence

    "PANA messages are retransmitted based on a timer until ..."

    Minor editorial note, maybe better to clarify with

    "PANA request messages are retransmitted based on a timer until ..."

* Sec 5.4 Message Authentication, Last Paragraph, last sentence

    "When the PaC does not support the integrity algorithm specified
     in the PANA-Bind-Request message, it MUST silently discard the
     message."

    Based on the ongoing changes in the PANA FSM doc, when the Pac
    silently discards PBR because of an un-supported algorithm
    and takes no other action, the PaC can get stuck in the same state
    forever despite the re-transmission of the PBR. The PAA eventually
    closes and cleans up because of failed re-transmission but the PaC
    may not since it may keep waiting for a good PBR. It maybe better
    to add text that says the PaC session should be close the session
    as well when a mis-match algorithm is found in the PBR.

* Sec 6.1 IP and UDP Headers, 1st Paragraph, 1st sentence

    "Any PANA message is unicast between the PaC and the PAA."

    This is very minor and I'm not sure if this would be problematic
    but should we say that the pana message exchanges for a session be
    restricted to the same PaC interface ? This is in the case of
    multi-homed PaC.

* Sec 8.5.  Failed-Message-Header AVP, 1st Paragraph, 1st sentence

    "The Failed-Message-Header AVP (AVP Code 5) provides debugging
     information in cases where a request is rejected or not fully
     processed due to erroneous information in a specific AVP. .."

    Editorial. Maybe it the text meant ...

    "The Failed-Message-Header AVP (AVP Code 5) provides debugging
     information in cases where a message is rejected or not fully
     processed due to erroneous information its header."

* Sec 8.8.  Result-Code AVP, 1st Paragraph, Last sentence

    "Here are Result-Code AVP values taken from [RFC3588] and adapted
     for PANA."

    Should we still retain the last sentence above if Sec 8.8.2.
    does not really follow 3588 value mapping, i.e. there is no
    longer a distinction between protocol, permanent, ... etc
    categories.

* Just a general question, Excerpt from Figure 1 is the exchange below:

   // Authentication and authorization phase
   <-----     PANA-Auth-Request /* EAP Request */
    ----->     PANA-Auth-Answer

   In the example PAR/PAN exchange above. If for every transmission
   including re-transmission of the PAR, the corresponding PAN sent
   by the PaC gets lost. In this case the PAA will eventually give up
   and disconnect however the PaC does not have a way to know that
   the session failed and that it needs to cleanup. Sorry if this
   has already been addressed somewhere and I have not seen it yet.

best regards,
victor

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 27 Nov 2006 20:10:05 -0500

>   unique as described previously in pana-pana-12 ?

It does not have to be global and eternally unique.  It is just 
unique within PAA during the lifetime of the session.  We can 
revise the text

from:

"
   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 handshake phase and freed when the
      session terminates.  The session identifier is assigned by the
      PAA.
"

to:

"
   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 handshake phase and freed when the
      session terminates.  The session identifier is assigned by the
      PAA and unique within the PAA during the lifetime of the session.
"

>    I'm not sure which error request the text is refering to.

This is a leftover of pana-pana-12.  We can safely delete this
sentence.

>    as well when a mis-match algorithm is found in the PBR.

Immediately terminating the session due to algorithm mismatch can be a
place for DoS attack and is not good.  We can use an explicit
disconnect message from the other end, a finite session lifetime or
failed liveness tests for clean up the session at the PaC side, by
adopting the general session termination guidelines described in
Section 3:

"
   o  Termination phase: The PaC or PAA may choose to discontinue the
      access service at any time.  An explicit disconnect message can be
      sent by either end.  If either the PaC or the PAA disconnects
      without engaging in termination messaging, it is expected that
      either the expiration of a finite session lifetime or failed
      liveness tests would clean up the session at the other end.
"

>    restricted to the same PaC interface ? This is in the case of

Isn't this obvious according to the following definition?

"
   PANA Session:

      A PANA session begins with the handshake 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,
      session lifetime expiration, or an explicit termination message.
      A fixed session identifier is maintained throughout a session.  A
      session cannot be shared across multiple network interfaces.  Only
      one IP address of the PaC is allowed to be bound to a PANA session
      for simplicity.
"

>     processed due to erroneous information its header."

OK.  Since errors can happen in AVPs or header or both, I'd 
revise the text something like:

  "The Failed-Message-Header AVP (AVP Code 5) provides debugging
   information in cases where a request is rejected or not fully
   processed due to erroneous information in the message."

>    longer a distinction between protocol, permanent, ... etc

This is another leftover.  We can change the text to:

"Result-Code AVP values are described in the subsequent sections."

>   has already been addressed somewhere and I have not seen it yet.

Again this could be handled by adopting the general session
termination guidelines described in Section 3.

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 29 Nov 2006 02:36:30 +0100

Hi Yoshi,Alper, all

I have been reviewing the doc.In general, it is ok for me.

Only some two minor comments:

Page 13:

"The MSK and the PANA session MUST be deleted
   immediately after the PANA-Bind message exchange."

I think I missed something...could anybody point me where this was discussed to understand the reason behind? or is it a mistake?

Initially i think PANA session should not be removed. On the other hand, with this text PANA does not allow MSK caching. Taking into account all references to bootstrapp security
has been removed it seems coherent because MSK won't be used further. However, i was wondering why this limitation.

Section 4.4. says :

"A Nonce AVP MUST be included in the first PANA-Auth-Request and PANA-
   Auth-Answer messages."

However , Figure 9 (table) has 0-1 for PAR/PAN

I guess it should be 1 taking into account the text above (on the other hand, that Nonce AVP would not be needed if EAP method is not able to generate cryptographic material)

Best Regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Depto. Ing. de la Info. y las Comunicaciones
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: [email-masked]
------------------------------------------------------

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 29 Nov 2006 14:14:17 -0500

Hi Rafa,

Thank you for the review.  Please see my comment below.

On Wed, Nov 29, 2006 at 02:36:30AM +0100, Rafa Marin Lopez wrote:
> I think I missed something...could anybody point me where this was 
> discussed to understand the reason behind? or is it a mistake?
> 
> Initially i think PANA session should not be removed. On the other hand, 
> with this text PANA does not allow MSK caching. Taking into account all 
> references to bootstrapp security
> has been removed it seems coherent because MSK won't be used further. 
> However, i was wondering why this limitation.

Note that the above behavior is in the context of the following case:

"
   There is a case where EAP authentication succeeds with producing an
   EAP Success message but network access authorization fails due to,
   e.g., authorization rejected by a AAA or authorization locally
   rejected by the PAA.  
"

This means, if authorization fails then the PANA session must be
deleted even if the EAP authentication has succeeded.  So the current
text should be ok.

> I guess it should be 1 taking into account the text above (on the other 
> hand, that Nonce AVP would not be needed if EAP method is not able to 
> generate cryptographic material)

It is true that Nonce AVP will not be used if MSK is not generated.
However, since PANA layer should not know which EAP method is in use
or is able to generate MSK, the only way is to mandate Nonce AVP in
the first PAR/PAN exchange.

The occurence table stating that Nonce AVP is 0-1 for PAR/PAN is
correct.  This is because Nonce AVP is carried only in the first
PAR/PAN exchange in authentication and authorization phase and
re-authentication phase, and it is not carried in other PAR/PAN
exchanges.

Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 30 Nov 2006 17:43:48 +0200

Yoshi,

Thanks a lot for the revision.

Here I have few comments and suggestions.

   By the virtue of enabling transport of EAP
   above IP, any authentication method that can be carried as an EAP
   method is made available to PANA and hence to any link-layer
   technology with a minimum link-layer dependency.  There is a clear

Alper> What's that dependency?

   There are components that are part of a complete secure network
   access solution but are outside of the PANA protocol specification,
   including IP address configuration, authentication method choice,
   data traffic protection, PAA-EP protocol, and PAA discovery.  PANA
   authentication output is used for creating access control filters.
   These components except for IP address configuration are described in
   separate documents (see [I-D.ietf-pana-framework],
   [I-D.ietf-pana-snmp] and [I-D.ietf-dhc-paa-option]).  The IP address
   configuration component may be specified in deployment-specific PANA
   applicability documents.  The readers are recommended to read the
   PANA Framework document [I-D.ietf-pana-framework] prior to reading
   this protocol specification document.

Alper> "IP address configuration" is not really part of a secure network
access solution. I'd recommend this re-write of the above paragraph:

   There are components that are part of a complete secure network
   access solution but are outside of the PANA protocol specification,
   including authentication method choice,
   data traffic protection, PAA-EP protocol, and PAA discovery.  PANA
   authentication output is used for creating access control filters.
   These components are described in
   separate documents (see [I-D.ietf-pana-framework],
   [I-D.ietf-pana-snmp] and [I-D.ietf-dhc-paa-option]).  
   The readers are recommended to read the
   PANA Framework document [I-D.ietf-pana-framework] prior to reading
   this protocol specification document.

      The protocol entity in the access network whose responsibility is
      to verify the credentials provided by a PANA client (PaC) and
      authorize network access to the access device associated with the
      client.  The PAA and the EAP authenticator (and optionally the EAP

Alper> I'd remove "associated with the client."

Alper> i think we can remove the last sentence. Sure we don't explicitly
support multi-homed clients, but no need to explicitly limit to single-homed
either. Being silent is a better choice.

   The PAA MAY refrain from retransmitting the PANA-Start-Request
   message to maintain as less amount of state as possible in the
   handshake phase.  For this reason, the PaC MUST retransmit the PANA-
   Client-Initiation message until it enters the authentication and
   authorization phase by receiving a PANA-Auth-Request message from the
   PAA.

Alper> Just to add a bit more elaboration (to prevent questions), I can
recommend 

   In order to prevent potential DoS attacks, the PAA MAY refrain from 
   timeout-based retransmission of the PANA-Start-Request
   message in response to a PaC-initiated handshake. For this reason, 
   the PaC MUST retransmit the PANA-Client-Initiation message until it 
   enters the authentication and authorization phase by receiving 
   the first PANA-Auth-Request message from the PAA. 

   session, it MUST silently discard the message.  Transmission of this
   error request is made optional in case this behavior is leveraged for
   a DoS attack on the PAA.  A Nonce AVP MUST be included in the first

Alper> There is no more error message generation. Hence the sentence
starting with "Transmission of this..." shall be deleted.

   If IPsec is used between the PaC and the EPs, an IKE [RFC2409] IKEv2
   [RFC4306] or MOBIKE [RFC4555] run is needed following such a change.

Alper> This is not something for the base PANA specification to state. It's
for PANA-ipsec document. Let's remove the above paragraph.

   messages MUST be protected with an AUTH AVP.  The PAA may also need
   update the per-packet enforcement policies of the EPs, however, this
   is out of the scope of this document.

Alper> This last sentence shall be removed too. As you said, it's out of
scope.

   For other PANA messages, the source port MUST be set to a value
   chosen by the sender. and the destination port MUST be set to the

Alper> Remove "."

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

Alper> this shall be under the informative references.

Thank you.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 30 Nov 2006 11:14:43 -0500

> Alper> What's that dependency?

There is no link-layer dependency in the PANA protocol itself but
there is some link-layer dependency in the entire PANA framework
including EP which can be link-layer devices according to
pana-framework I-D.  

Perhaps we can remove "with a minimum link-layer dependency" since
this I-D is about the PANA protocol itself.

>    this protocol specification document.

OK.

> Alper> I'd remove "associated with the client."

OK.

> either. Being silent is a better choice.

I agree.

>    the first PANA-Auth-Request message from the PAA. 

OK.

> starting with "Transmission of this..." shall be deleted.

Yes (and there is similar comment from Victor).

> for PANA-ipsec document. Let's remove the above paragraph.

OK.

> Alper> This last sentence shall be removed too. As you said, it's out of

OK.

>    chosen by the sender. and the destination port MUST be set to the

OK.

> Alper> this shall be under the informative references.

OK.

Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 30 Nov 2006 22:35:30 -0500

(snip)

>     processed due to erroneous information its header."

I found additional minor errors.  

- Since a PANA-Error-Request may be sent not only in response to a
request but also in response to an answer, it should say "message" in
stead of "request".  The same comment goes to Failed-AVP AVP.

- Also, Failed-AVP AVP format needs to be described in stead of
referring to RFC 3588 because it uses its own AVP Type (4) value
instead of that for Diameter Failed-AVP AVP (279).

So here is the new text for Sections 8.4 and 8.5:

"
8.4.  Failed-AVP AVP

   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.5.  Failed-Message-Header AVP

   The Failed-Message-Header AVP (AVP Code 5) provides debugging
   information in cases where a message is rejected or not fully
   processed due to erroneous information in the message.  The AVP data
   is of type OctetString.  The AVP data contains the 16-octet header of
   the message that caused the error.
"

Regards,
Yoshihiro Ohba