Subject: [Pana] comments on the review of pana-08

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 06 Jun 2005 16:06:35 -0400

Hi Jari,

Thank you for the comments on the PANA specification.  Please see my
comments in line:

> 
> Technical:
> 
> 
>    PANA can carry any
>    authentication method that can be specified as an EAP method, and it
>    can be used on any link that can carry IP.
> 
> 
> The former part may be too strong, particularly if we start dictating
> what requirements EAP methods must meet. I think its easy to just delete
> this part from the abstract, or change it to "Different authentication
> methods can be used within the EAP framework, and PANA can be
> used over different types of links as long as those carry IP."

I think we can delete this part.

> 
> 
>    o  If the first EAP authentication has failed, the PAA can choose not
>       to perform the second EAP authentication by clearing the S-flag of
>       the PANA-FirstAuth-End-Request message.  In this case, the S-flag
>       of the PANA-FirstAuth-End-Answer message sent by the PaC MUST be
>       cleared.  If the S-flag of the PANA-FirstAuth-End-Request message
>       is set when the first EAP authentication has failed, the PaC can
>       choose not to perform the second EAP authentication by clearing
>       the S-flag of the PANA-FirstAuth-End-Answer message.  If the first
>       EAP authentication failed and the S-flag is not set in the PANA-
>       FirstAuth-End-Answer message as a result of those operations, the
>       PANA session MUST be immediately deleted.  Otherwise, the second
>       EAP authentication MUST be performed.
> 
> 
> I think we may have discussed this in the past, but I still don't
> understand why we need to continue if one of the authentications
> fail. Is there a specific real-world scenario where this would be useful?

This is to deal with the case where NAP and ISP provides independent
authorization.  There is a requirement on this in section 4.1.1 of RFC
4058.  As far as I remember the discussion a few years ago, one usage
scenario is that a NAP providing its own contents service within the
access network.

> 
> 
>          When the S-flag is set in a PANA-Start-Request message it
>          indicates that PAA is willing to offer separate NAP and ISP
>          authentication.  When the S-flag is set in a PANA-Start-Answer
>          message it indicates that the PaC accepts on performing
>          separate NAP and ISP authentication.  The PaC may also respond
> 
> 
> I'd like to understand whether the S-flag can also appear in
> the Reauth-Request message or not. If yes, does this mean that
> the initial 2-step authentication can change to a 1-step authentication
> in the reauth phase?

Yes, and the S-flag value needs to be inherited from the previous
authentication and authorization phase or re-authentication phase.

I think we should update section 4.5:

"
   For any re-authentication, if there is an established PANA SA, PANA-
   Auth-Request and PANA-Auth-Answer messages MUST be protected by
   adding a MAC AVP to each message.  Any subsequent EAP authentication
   MUST be performed with the same ISP and NAP that was selected during
   the discovery and handshake phase.  An example sequence for re-
   authentication phase initiated by the PaC is shown in Figure 7.
"

to:

"
   For any re-authentication, if there is an established PANA SA,
   PANA-Auth-Request and PANA-Auth-Answer messages MUST be protected
   by adding a MAC AVP to each message.  Any subsequent EAP
   authentication MUST be performed with the same ISP and NAP that was
   selected during the discovery and handshake phase.  The value of
   the S-flag of the PANA messages exchanged in the re-authentication
   phase MUST be inherited from the previous authentication and
   authorization phase or re-authentication phase.
"

> 
> 
>       N (No configuration)
> 
> 
>          The PaC does not have to (if sent by PAA) or will not (if sent
>          by PaC) configure a new IP address after PANA.
> 
> 
>       D (DHCP)
> 
> 
>          The PaC can (if sent by PAA) or will (if sent by PaC) use DHCP
>          [RFC2131] [RFC3315] to configure a new IP address after PANA.
> 
> 
>       A (stateless autoconfiguration)
> 
> 
>          The PaC can/will use stateless IPv6 address autoconfiguration
>          [RFC2462] to configure a new IP address after PANA.
> 
> 
>       T (DHCP with IPsec tunnel mode)
> 
> 
>          The PaC can/will use [RFC3456] to configure a new IP address
>          after PANA.
> 
> 
>       I (IKEv2)
> 
> 
>          The PaC can/will use [I-D.ietf-ipsec-ikev2] to configure a new
>          IP address after PANA.
> 
> 
> Is there some guidance as to what bits must at least be
> set here? (ANd what do server/client sides have to support,
> as a consequence)?
> 
> 
> First guess: either N or one of the other bits must be set.
> 

Yes.  We can add the following text in section 7.3.11.

"
When this AVP is included in a PANA-Start-Request or PANA-Bind-Request
message, either N-flag or one of the other flags MUST be set.
"

> 
> ALso, is there a difference wrt IPv6 and IPv4 here? What if you want to
> retrieve both IPv4 and IPv6 addresses after the authentication
> has occurred.

I think this is related to one of the framework issue.  Depending on
reslution of the framework issue, if it turns out that some change is
needed in the PANA specification, we will update the spec to reflect
the framework issue.

> 
> 
> Security considerations stemming from the use of EAP and
> EAP methods are discussed in [RFC3748].
> 
> 
> Perhaps you should add eap-keying as an (informational)
> reference here.

OK.

> 
> 
>    A return-
>    routability test does not provide additional protection as PANA
>    traffic is not routed but simply forwarded on-link.  It is difficult
>    to prevent this threat entirely.
> 
> 
> This sentence may have to be revised a bit, now that we allow
> multiple hops.

I agree.  It can be revised something like:

"
    A return-
    routability test does not provide additional protection when PANA
    traffic is not routed but simply forwarded on-link.  It is difficult
    to prevent this threat entirely.
"

> 
> 
> Editorial:
> 
> 
>     networks and 3GPP2 networks with crytographically-secured cdma2000 
> 
> 
> 
> Either this is a new technique, or s/cryto/crypto/

It is a typo.  I'll fix it.

> 
> 
>    5.   Protocol Design Details and Processing Rules . . . . . . . .  25
>      5.1  Transport Layer  . . . . . . . . . . . . . . . . . . . . .  25
>        5.1.1  Fragmentation  . . . . . . . . . . . . . . . . . . . .  25
>      5.2  Sequence Number and Retransmission . . . . . . . . . . . .  25
> 
> 
> Looking at the contents page, it seems that 5.1 might better fit
> section 4, and then you could call section 5 simply as "Processing
> Rules". Maybe in that case also change s/6. PANA Headers and Formats/
> 6. Header Format/, and maybe even split section 7 to two independent
> parts, one to describe messages and another one to describe AVPs.

Yes, all these comments on the document structure make sense.

> 
> 
>    There are components that are part of a complete secure network
>    solution but are outside of the PANA protocol specification,
> 
> 
> s/network solution/network access solution/

OK.

> 
> 
> either the expiration of a finite session lifetime or failed
> liveness tests would do the job.
> 
> 
> s/would do the job/would clean up the session at the other end/
> 

OK.

> 
>     administratively scoped multicast address (TBD) and UDP port (TBD). 
> 
> 
> I have found that s/TBD/To Be Assigned by IANA/ is
> easier from the point of view of the later processing of
> this draft, as the IANA can simply search for its name.

OK.

Thank you,

Yoshihiro Ohba

> --Jari

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

---

From: Alper Yegin <[email-masked]>
Date: Tue, 14 Jun 2005 14:34:41 -0700

Hi Jari, Yoshi,

Let me inject some input into this thread.

> scenario is that a NAP providing its own contents service within the

We treat NAP authentication as an optional feature. NAP may provide
differentiated services to authenticated subscribers. Our thinking was
that, since this is an optional authentication, its failure should not
fail the overall "network access authentication." If it is going to
provide considerable amount of protocol simplification, I'd not object
to changing this now. I guess, if PANA authentication fails due to NAP
authentication failure, PAC can try again with ISP-only authentication.

> message, either N-flag or one of the other flags MUST be set.

In fact, more than one of D, A, T, I flags may be set. T or I may be set
only when IPsec-based access control is used. D or A may be set
otherwise.

>     to prevent this threat entirely.

Isn't return routability test inherently built into the PANA due to its
multi-round-trip nature?

Alper

---

From: Jari Arkko <[email-masked]>
Date: Wed, 15 Jun 2005 06:41:18 +0300

Alper Yegin wrote:

>>>fail. Is there a specific real-world scenario where this would be
>>>      
>>>
>>useful?
>>
Yes. Note that I'm not objecting to having double authentication.
That seems useful. I'm just wondering why we need to continue
if we fail one authentication.

(If we do allow both NAP auth and no NAP auth, are there enough
bits in the messages to convey this optionality? I can also imagine
a situation where the NAP auth is always mandatory.)

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 15 Jun 2005 07:07:43 -0400

Hi Jari,

> a situation where the NAP auth is always mandatory.)

This issue was discussed last year and we decided to not make NAP
authentication mandatory:

http://danforsberg.info:8080/pana-issues/issue150

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 20 Jun 2005 15:32:39 -0400

> only when IPsec-based access control is used. D or A may be set

You are right.  I'll incorporate this.

> Isn't return routability test inherently built into the PANA due to its

Yes, it is (with stateless PAA discovery).  So it might be good to
simply remove this sentence, and revise the paragraph something like:

"
   The discovery and handshake phase is vulnerable to spoofing attacks
   as these messages are not authenticated and integrity protected.  In
   order to prevent very basic denial-of service attacks an adversary
   should not be able to cause state creation by sending discovery
   messages to the PAA.  This protection is achieved by using a cookie-
   based scheme (similar to [RFC2522] which allows the responder (PAA)
   to be stateless in the first round of message exchange.  However, it is
   difficult to prevent all spoofing attacks in the discovery and
   handshake phase entirely.
"

Regards,

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Mon, 20 Jun 2005 15:01:59 -0700

Looks good, thank you.

Alper

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]]
> Sent: Monday, June 20, 2005 12:33 PM
> To: Alper Yegin
> Cc: 'Yoshihiro Ohba'; [email-masked]
> Subject: Re: [Pana] comments on the review of pana-08
>