Subject: [Pana] NEW: [issue52] Details of double authentication

From: [email-masked]
Date: Thu, 5 Feb 2004 11:40:50 +0200

Dan Forsberg <[email-masked]> added the comment:

>Jari Arkko wrote:
>      - "Details of double authentication"
> 
>        Perhaps its just me, but I did not find all the details
>        regarding the use of two (NAP and ISP) authentications. Is
>        this supported or not? Are they performed in sequence? Does it
>        look like a re-authentication, or do you provide a bit
>        somewhere that indicates whether this EAP run relates to the
>        NAP or the ISP authentication? Is there a PANA Bind Request -
>        Answer pair in between or not?

Alper Yegin:
This says the text is not sufficient. We shall open an issue on this and try
to clearly answer your questions.
__________________________________________________
PANA Issues <[email-masked]>
<http://danforsberg.info:8080/pana-issues/issue52>
__________________________________________________
=�ڙ���x%��Ojv�z��m��?�0�'�~���f��f��X��)ߣ�Z�

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 11 Feb 2004 12:13:30 -0800

On Thu, Feb 05, 2004 at 11:40:50AM +0200, [email-masked] wrote:
> >        this supported or not? Are they performed in sequence? 

PANA supports two EAP sequences, one for NAP authentication and the
other ISP authentication.  They are performed in sequence.  These are 
not explicitly specified in the draft and need to be revised.

Here is my suggested text on this:

- Change the first paragraph of section 4.3

"                                                                                
   The main task in authentication phase is to carry EAP messages
   between PaC and PAA. All EAP messages except for EAP Success/Failure
   messages are carried in the PANA-Auth-Request/PANA-Auth-Answer
   messages.  When an EAP Success/Failure message is sent from a PAA,
   the message is carried in the PANA-Bind-Request message.  The PANA-
   Bind-Request message is acknowledged with a PANA-Bind-Answer.  It is
   possible to carry multiple EAP sequences in a single PANA session.
"
                                                                                
to:

"
   The main task in authentication phase is to carry EAP messages
   between PaC and PAA. All EAP messages except for EAP
   Success/Failure messages are carried in the
   PANA-Auth-Request/PANA-Auth-Answer messages.  When an EAP
   Success/Failure message is sent from a PAA, the message is carried
   in the PANA-Bind-Request message.  The PANA-Bind-Request message is
   acknowledged with a PANA-Bind-Answer.  PANA supports two EAP
   sequences to be sequencially performed in a single PANA session,
   where an PANA-Bind-Request/Answer exchange occurs at the end of
   each EAP sequence.
"

> >        Does it

PAA can indicate which EAP sequence is for which (NAP or ISP) authentication.
This is specified in section 4.3.

Also, I think it might be good to add the following example of NAP and
ISP separate authentication as well as ISP selection in section in
section 4.6:

"
   Another PANA message sequence is illustrated in Figure X.  The
   example assumes the following scenario:
                                                                                
   o  PaC multicasts PANA-PAA-Discover message
                                                                                
   o  The ISNs used by the PAA and the PaC are x and y, respectively.
      
   o  PAA offers NAP and ISP separate authentication, as well as a
      choice of ISP from "ISP1" and "ISP2".

   o  PaC accepts the offer from PAA, with choosing "ISP1" as the ISP.

   o  An EAP sequence for NAP authentication and an EAP sequence for
      ISP authentication is performed in this order in authentication phase.
                                                                                
   o  An EAP authentication method with a single round trip is used in
      each of EAP sequence.
                                                                                
   o  The EAP authentication methods derive keys.  The PANA SA is
      established based on the unique and fresh session key provided by
      the EAP method in the first EAP sequence.
                                                                                
   o  After PANA SA is established, all messages are integrity and
      replay protected with the MAC AVP.
                                                                                
   o  Re-authentication and termination phase are not shown.

     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")]
         ----->     PANA-Auth-Answer(y+1,x+1)[EAP]
         <-----     PANA-Auth-Request(x+2,y+1)[EAP]
         ----->     PANA-Auth-Answer(y+2,x+2)[EAP]
         <-----     PANA-Bind-Request(x+3,y+2)
                      [EAP{Success}, Device-Id, 
                       Key-Id, Lifetime, Protection-Cap., MAC]
         ----->     PANA-Bind-Answer(y+3,x+3)
                      [Device-Id, Key-Id, Protection-Cap., MAC]
                                                                                
         <-----     PANA-Auth-Request(x+3,y+4)         // ISP authentication
                    [EAP, ISP-Information("ISP1")]
         ----->     PANA-Auth-Answer(y+4,x+4)[EAP]
         <-----     PANA-Auth-Request(x+4,y+5)[EAP]
         ----->     PANA-Auth-Answer(y+5,x+5)[EAP]
         <-----     PANA-Bind-Request(x+5,y+6)
                      [EAP{Success}, Device-Id, Lifetime, Protection-Cap., MAC]
         ----->     PANA-Bind-Answer(y+6,x+5)
                      [Device-Id, Protection-Cap., MAC]

        Figure X: A Message Sequence for NAP and ISP Separate Authentication
"                                                                                

Yoshihiro Ohba

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 11 Feb 2004 12:13:30 -0800

"                                                                                
                                                                                
to:

"

"

      

                                                                                

                                                                                

      // Authentication phase

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Tue, 17 Feb 2004 18:56:25 -0800

Hi Yoshi,

Thanks for taking a stab at this. I have some comments below.

>  where an PANA-Bind-Request/Answer exchange occurs at the end of

Now that EAP messages can be carried over PSR-PSA, I think we need to
reflect that to the text above.

Btw, giving an example PANA sequence is a good idea.

Your clarifications are good. Here are couple other things to consider for
tying the loose ends:

- I guess this scheme works even if the PAA does not advertise a list of
ISPs. The PaC can still perform separate authentication. But I suspect we
assume PAA must advertise a NAP-info, or else this doesn't work. Right? If
so, we shall spell this out. Also, the assumption is that PAA belongs to a
single NAP, hence at most one NAP-info is included at any time.

- If the first round of EAP fails, and PaC does not want to continue, what
happens? Maybe we should add something to PBA to signal that.

Same with PAA wishing to abort the session? Some indication in PBR can be
useful here.

- We should note that if this is the first run of PANA, the per-packet
protection kicks in only after the successful completion of PANA (i.e.,
after the second EAP run).

- Including some AVPs after the first PBR doesn't make sense. For example
device Id (?), session lifetime, protection capability... We might want to
consider defining a new PANA message that is only used to delimeter to EAP
sequences for split NAP-ISP authentication. This can provide overall
simplification, I believe.

- Also Jari had these comments:

    Why is there no problem with the mitm attacks in the PANA
    authentication sequences, as there are in other EAP sequencing?
    ...
JARI: (Substantial) If the two MSKs are not somehow cryptographically
      bound to each other, a mitm attack remains a possibility. See
      draft-puthenkulam-eap-binding-04.txt.

Any thoughts on this?

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 17 Feb 2004 18:56:25 -0800

Hi Yoshi,

Any thoughts on this?

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 20 Feb 2004 20:20:53 -0800

> reflect that to the text above.

OK.  I think that when a PSR is sent with S-bit set, it should not
contain an EAP message because the negotiation on NAP/ISP separate
authentication is not done yet.

> single NAP, hence at most one NAP-info is included at any time.

I think the current text in the second paragraph of Section 4.3
already describes this.

> happens? Maybe we should add something to PBA to signal that.

In the current design, there is no option for a PaC that has accepted
an offer from PAA to perform separate authentication in the discovery
and initial handshake phase to decline the 2nd round of EAP.  If we
want to add the functionality to decline the 2nd round of EAP in this
case, we might use S-bit not only for the discovery and initial
handshake phase but also for the authenticatioin phase (i.e., When
S-bit is cleared in PBA message while it is set in PBR message, it
means that the PaC does not want to continue to 2nd EAP round).

> Same with PAA wishing to abort the session? Some indication in PBR can be

If the PAA aborts the session just because the 1st EAP round fails, 
PaC cannot continue to the 2nd EAP round even if it wishes to do it.
I think PAA should not aborts the session once the PaC has accepted 
the offer to perform NAP/ISP separate authentications.

> after the second EAP run).

Yes.

> simplification, I believe.

I agree.   

>       draft-puthenkulam-eap-binding-04.txt.

The two MSKs (or AAA-Keys) should be cryptographically bound to each
other unless lower-layer is secured.  When lower-layer is not secured,
the PANA-Auth-Request/Answer exchange for the second EAP round must be
protected with a MAC AVP.  This means that the EAP method used in the
first EAP round must generate a AAA-Key.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 20 Feb 2004 20:20:53 -0800

Yes.

I agree.   

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Tue, 24 Feb 2004 13:25:26 -0800

> > ISPs. The PaC can still perform separate authentication. But I
suspect
> we
> > assume PAA must advertise a NAP-info, or else this doesn't work.
Right?
> If
> > so, we shall spell this out. Also, the assumption is that PAA
belongs to
> a

Right, it is implicitly there. That's fine.

> 
> >
> > - If the first round of EAP fails, and PaC does not want to
continue,
> what

Or a separate, dedicated bit can be defined...

> 
> >
> > Same with PAA wishing to abort the session? Some indication in PBR
can
> be

The actions to be taken when NAP auth fails/succeeds, and ISP auth
fails/succeeds are left to the deployment. Along with this flexibility,
I thought we should also allow the access network to abort the AAA when
first round AAA fails. 

Alper

---

From: Alper Yegin <[email-masked]>
Date: Tue, 24 Feb 2004 13:25:26 -0800

suspect
Right?
belongs to

continue,

can

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 24 Feb 2004 21:57:28 -0800

> Or a separate, dedicated bit can be defined...

In the state machine, a variable SEPARATE controls whether to perform
separate authentication and it is tied with S-bit.  I think the same
variable can be used for this scenario and using the same S-bit for
changing the same variable seems reasonable to me.

> I thought we should also allow the access network to abort the AAA when

OK.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 24 Feb 2004 21:57:28 -0800

OK.

Yoshihiro Ohba