Subject: [Pana] comments on pana-03a

From: Julien Bournelle <[email-masked]>
Date: Fri, 23 Jan 2004 16:17:46 +0100

hi,

 I have a few questions/comments regarding the draft pana-03a:

-1- The PAA set the S-flag if we want to do ISP and NAP authentication
and the PaC set the S-flag if it is ok. But what do we do if pac does
not set the S-FLag ?

-2- In the outline, 4.2 is "Discovery and Initial handshake" 4.3 is
"Authentication phase when PANA-PAA-Discover is sent by EP" 4.4 is
"Re-authentication" so we may have the impression that the case where
the PANA-PAA-Discover is sent by the pac is not considered. 

Maybe we could just rename 4.3 with "Authentication Phase".

-3- Correct me if I'm wrong but I guess the draft CMS Application
Diameter is no longer supported by AAA wg 
and
draft-aboba-pppext-key-problem-07  is now 
draft-ietf-eap-keying-01.txt

-4- The PAA can indicate that IPsec is supported by the Protection
Capability AVP sent in the PANA-Bind-Request. 
As the pac can not indicate if it support it, the PAA is going to
configure the EP for enabling IPsec (cf draft-ietf-pana-ipsec-01.txt). 
As such, EP will set up its SPD and will
accept only ipsec traffic.

SO finally, when PAA sets the protection capability with IPsec protection
it implicitely requires that pac MUST support IPsec to access network.

I wonder if it is what we want.

what do you think ? (Am I missing ?)

-- 
[email-masked]

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 23 Jan 2004 08:37:14 -0800

Hi Julien,

> and the PaC set the S-flag if it is ok. But what do we do if pac does

When PaC does not set the S-fLag, only one EAP authentication occurs.
I will add this explicit text.

> Maybe we could just rename 4.3 with "Authentication Phase".

That is a typo.  I'll rename it as you suggest.

> draft-ietf-eap-keying-01.txt

That is true.  To deal with the CMS issue, how about removing the
following sentence in item c) of Section 11?

  "Draft [I-D.ietf-aaa-diameter-cms-sec] describes how a session key
  is securely carried (i.e. CMS protected) between AAA servers. "

I will also update the reference to the eap-keying draft.

> I wonder if it is what we want.

That is what we want.  Protection capability is non-negotiable.  In
addition, the PaC that is incapable of IPsec should not return the
PANA-Bind-Answer in this case.  Instead, it should return an
unprotected PANA-Error message with an appropriate Result-Code, and
the PAA should treat the Error as an informational message and should
neither enable IPsec nor immediately delete the session for the PaC.
Instead, the PAA should wait for the authentication to timeout or for
the number of retransmission to reach the maximum value.

I think we might need to define a new Result-Code to explicit support 
the above case, such as:

"  PANA_PROTECTION_CAPABILITY_UNSUPPORTED     5016
                                                                             
      Error code from PaC to PAA.  This error is returned when the PaC
      receives a PANA-Bind-Request is received with an
      Protection-Capability AVP and a valid MAC AVP but does not
      support the protection capability specified in the
      Protection-Capability AVP."

What do you think?

Thanks,

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 23 Jan 2004 08:37:14 -0800

Hi Julien,

                                                                             

What do you think?

Thanks,

Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Mon, 26 Jan 2004 14:19:08 +0100

Hi,

> I will add this explicit text.

ok, but in this case, which EAP authentication occurs ? (ISP ?)

> I will also update the reference to the eap-keying draft.

ok

>       Protection-Capability AVP."

I think that we need this error message.

---

From: Julien Bournelle <[email-masked]>
Date: Mon, 26 Jan 2004 14:19:08 +0100

Hi,

ok

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 26 Jan 2004 17:18:53 -0800

> ok, but in this case, which EAP authentication occurs ? (ISP ?)

I think in this case there is no distinction between NAP and ISP
authentication (but the PaC can still declare its desire to use
specific ISP).

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 26 Jan 2004 17:18:53 -0800

Yoshihiro Ohba

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 29 Jan 2004 15:21:35 +0100

Hi yoshihiro, 

> authentication (but the PaC can still declare its desire to use

well, I'm not sure to well understand.. if the PAA sets the S-flag, it
means that there is a distinction between NAP and ISP. So, if the pac
does not the S-flag, I can understand that there is only one EAP
authentication but either the NAP or the ISP couldn't authenticate this
pac. Do I miss something ?

---

From: Julien Bournelle <[email-masked]>
Date: Thu, 29 Jan 2004 15:21:35 +0100

Hi yoshihiro,

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 29 Jan 2004 09:34:14 -0800

> pac. Do I miss something ?

If the PAA sets the S-flag, it means that a distinction between NAP
and ISP will be made if the PaC aggrees to have the distinction.  If
the PaC does not set the S-flag, it means the PaC did not agree to 
have the distinction, and no distinction is made as a consequence.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 29 Jan 2004 09:34:14 -0800

Yoshihiro Ohba