Subject: RE: [Pana] issue 52: proposed text

From: Alper Yegin <[email-masked]>
Date: Fri, 19 Mar 2004 04:27:56 +0000 (GMT)

Hi Yoshi,

Thanks for taking care of this issue.
Please see below for my comments.

> to:
> 
>    "A PANA SA is created as an attribute of a PANA session when EAP
>    authentication succeeds with a creation of a AAA-Key.  A PANA SA is
>    not created when the PANA authentication fails or no AAA-Key is
>    produced by any EAP authentication method. In the case where two
>    EAP authentications are performed in sequence in a single PANA
>    authentication phase, it is possible that two AAA-Keys are
>    derived. If this happens, the PANA SA MUST be bound to both

Somehow "bound to" sounds like PANA SA has two keys. Eventually it has
one PANA_MAC_KEY, that is generated from one or two AAA-keys. Maybe we s
hould say "PANA SA is generated from both AAA-Keys". 

Actually, it is even "PANA SA is generated from the AAA-keys available at 
the time."  After the first auth (NAP, for example), it is generated from the AAA-key 
if the auth was a success. After the second auth (ISP), again all the keys
from the successful auth rounds are used with the resultant PANA SA.
 
> to:
> 
> "
>    When a Cookie-AVP is carried in a PANA-Start-Request message, the
>    initial EAP Request MUST NOT be carried in the PANA-Start-Request
>    message in order for the PAA to be stateless.
> 
>    When a Cookie-AVP is not carried in a PANA-Start-Request message, the
>    PAA does not need to be stateless.  In this case, the initial EAP
>    Request message MAY be carried in the PANA-Start-Request message.

The real "cause" to not use this optimization is the "stateless PAA discovery". 
Cookie usage is just another "result". So, I'd say:

"Initial EAP Request MAY be optionally carried by the PANA-Start-Request (as
opposed to by a later PANA-Auth-Request) message in order to reduce
the number of round-trips. This optimization SHOULD not be used if the 
PAA discovery is desired to be stateless."

> Rewrite Section 4.3 as follows:
> 
> 4.3 Authentication Phase
> 
>    The main task in authentication phase is to carry EAP messages
>    between PaC and PAA.  EAP Request messages are carried in PANA-
>    Auth-Request messages and optionally carried in PANA-Start-Request
>    messages.  EAP Response messages are carried in PANA-Auth-Answer
>    messages and optionally carried in PANA-Start-Answer messages.
>    When an EAP Success/Failure message is sent from a PAA, the message
>    is carried in a PANA-Bind-Request (PBR) or
>    PANA-FirstAuth-End-Request (PFER) message.  The
>    PANA-FirstAuth-End-Reques message MUST be used at the end of the
>    first EAP when the PaC and PAA have negotiated during the discovery
>    and initial handshake phase to perform separate NAP and ISP
>    authentications in a single PANA authentication phase.  Otherwise,
>    the PANA-Bind-Request message MUST be used.  The PANA-Bind-Request
>    and PANA-FirstAuth-End-Request messages MUST be acknowledged with a
>    PANA-Bind-Answer (PBA) and a PANA-FirstAuth-End-Answer (PFEA)
>    messages, respectively.
> 
>    When the PaC and PAA have negotiated during the discovery and
>    initial handshake phase to perform separate NAP and ISP
>    authentications, the S-flag of PANA-Auth-Request and
>    PANA-Auth-Answer messages MUST be set.  Otherwise, the S-flag MUST
>    NOT be set.
> 
>    When separate NAP and ISP authentications are performed, the PAA
>    determines the execution order of NAP authentication and ISP
>    authentication.  In this case, the PAA can indicate which EAP
>    authentication is currently occurring by including a
>    NAP-Information or an ISP-Information AVP of the corresponding EAP
>    authentication in the first PANA-Auth-Request message sent to the
>    PaC. 

I guess we could also use a single (or two) bit to indicate this is a NAP auth. 
round vs. ISP auth. round.

> In the case where the PaC agreed to perform separate
>    authentications but did not specify its ISP choice in
>    PANA-Start-Answer message, the PAA MUST include its NAP-Information
>    AVP in PANA-Auth-Request message when it performs NAP
>    authentication and MUST NOT include any service provider
>    information AVP when it performs ISP authentication so that the PaC
>    can always distinguish ISP authentication from NAP authentication.

"In the case where the PaC agreed to perform separate
authentications, presence or absence of NAP-information
AVP in PANA-Auth-Request message indicates the 
authentication type. The PAA MUST include its NAP-Information
AVP  when it performs NAP authentication, and it MUST NOT include
it for the ISP authentication. PAA MUST include the ISP-information
AVP for ISP authentication when the PaC has indicated its choice
of ISP."

>    The PAA SHOULD stop including a NAP-Information or an
>    ISP-Information AVP once it receives the first PANA-Auth-Answer
>    message of the current EAP authentication.

...

>    policy issue.  PANA signals only the result of the immediately
>    preceding EAP authentication method in PANA-Bind-Request messages.

We don't need this statement anymore, because PANA-Bind is only used at the 
end (after both rounds of auth.)

> Add the following example in section 4.6:
...
>       PaC      PAA  Message(tseq,rseq)[AVPs]
>       -----------------------------------------------------
>       // Discovery and initial handshake phase
>          ----->     PANA-PAA-Discover (0,0)
>          <-----     PANA-Start-Request (x,0)            // S-flag set
>                     [Cookie, ISP-Information("ISP1"),
>                      ISP-Information("ISP2"),
>                      NAP-Information("MyNAP")]
>          ----->     PANA-Start-Request-Answer (y,x)     // S-flag set
>                     [Cookie, ISP-Information("ISP1")]   // PaC chooses
> "ISP1"
> 
>       // Authentication phase
>          <-----     PANA-Auth-Request(x+1,y)            // NAP
> authentication
>                     [EAP, NAP-Information("MyNAP")]     // S-flag set
>          ----->     PANA-Auth-Answer(y+1,x+1)[EAP]      // S-flag set
>          <-----     PANA-Auth-Request(x+2,y+1)[EAP]     // S-flag set
>          ----->     PANA-Auth-Answer(y+2,x+2)[EAP]      // S-flag set
>          <-----     PANA-FirstAuth-End-Request(x+3,y+2) // S-flag set
>                       [EAP{Success}, Key-Id, MAC]
>          ----->     PANA-FirstAuth-End-Answer(y+3,x+3)[Key-Id, MAC]
>                                                         // S-flag set
> 
>          <-----     PANA-Auth-Request(x+3,y+4)          // ISP
> authentication
>                     [EAP, ISP-Information("ISP1")]      // S-flag set
>          ----->     PANA-Auth-Answer(y+4,x+4)[EAP]      // S-flag set
>          <-----     PANA-Auth-Request(x+4,y+5)[EAP]     // S-flag set
>          ----->     PANA-Auth-Answer(y+5,x+5)[EAP]      // S-flag set
>          <-----     PANA-Bind-Request(x+5,y+6)          // S-flag set
>                       [EAP{Success}, Device-Id, Key-Id,
>                        Lifetime, Protection-Cap., MAC]
>          ----->     PANA-Bind-Answer(y+6,x+5)           // S-flag set
>                       [Device-Id, Key-Id, Protection-Cap., MAC]

I think the MAC AVPs are missing in all messages of the second auth. round.

Alper

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 17 Mar 2004 10:36:31 -0800

> from the successful auth rounds are used with the resultant PANA SA.

OK.

> PAA discovery is desired to be stateless."

OK.

> round vs. ISP auth. round.

Yes.  I think that is a good idea.  I will try to 
introduce a flag when I send updated text on issue 52.

> end (after both rounds of auth.)

OK.

> I think the MAC AVPs are missing in all messages of the second auth. round.

OK.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 17 Mar 2004 10:36:31 -0800

OK.

OK.

OK.

OK.

Yoshihiro Ohba