Subject: [Pana] NEW: [issue54] Client cookie mandatory

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

New submission from Dan Forsberg <[email-masked]>:

From Jari Arkko:
>      - "Cookie mandatory"
> 
>        I would like the inclusion of the cookie to in the start
>        exchange to be mandatory.

----------
category: Technical
document: draft-ietf-pana-pana-xx.txt
messages: 194
nosy: dforsber
priority: Should Fix
status: Pending
title: Client cookie mandatory
__________________________________________________
PANA Issues <[email-masked]>
<http://danforsberg.info:8080/pana-issues/issue54>
__________________________________________________
ڝ���X��X����j'�~����i����
bz���j)fj��b��?���

---

From: Alper Yegin <[email-masked]>
Date: Fri, 06 Feb 2004 17:30:12 -0800

>>        exchange to be mandatory.

JARI: (Substantial) Great, but why a MAY? There does not appear to
      be any performance of complexity penalty of calculating
      such simple cookies. Why not do it every time?

In some environments, such as physically secured DSL networks, use of
cookies is not necessary. If a PaC launches a DoS attack, it'd be really
easy to detect and disable it. This is why we had made it a MAY. It is left
to the operator to decide. Even though it is a low-cost operation, we
thought operators might mind it given that they have alternative means.
Maybe we should provide such explanations around it.

      Cookie =
        <secret-version> | HMAC_SHA1( <Device-Id of PaC> | <secret> )

   where <secret> is a randomly generated secret known only to the PAA,
   <secret-version> is an index used for choosing the secret for
   generating the cookie and '|' indicates concatenation.  The secret-
   version should be changed frequently enough to prevent replay
   attacks. The secret key is locally known to the PAA only and valid
   for a certain time frame.

JARI: (Question) Is there a need to ensure that the cookies for
      two different sessions with the same device are different?
      The above does not provide that.

The cookie does not have any significance other than proving that the sender
really received and processed the previous message. So I think using the
same cookie even when the PaC is engaged in two separate sessions is fine.

Alper

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

---

From: Alper Yegin <[email-masked]>
Date: Fri, 06 Feb 2004 17:30:12 -0800

Cookie =

Alper

---

From: Jari Arkko <[email-masked]>
Date: Sat, 07 Feb 2004 03:39:39 +0200

> Maybe we should provide such explanations around it.

I understand, but I think the tradeoff is not good enough. It
costs very little, but making it optional implies another type
of cost in terms of configuration knobs, interop testing, danger
of the configuration knob being set wrong, and so forth.

The less moving parts, the better...

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 07 Feb 2004 03:39:39 +0200

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 09 Feb 2004 15:27:46 -0800

>From optimization point of view, mandating the cookie does not allow
EAP message to be carried in PSR and PSA any more.  This is because
cookie operation needs PAA to be stateless.  Jari also has a technical
comment on this.  It is true that authenticator can generate
EAP-Request message without creating state if we do not consider
retransmission of EAP-Request.  However, if we consider the fact that
EAP-Request needs to be retransmitted by the authenticator, some state
needs to be created at the authenticator.  If authentictor generates
EAP-Request but without retransmission, then such an implmentation
does not really comply with RFC2284bis.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 09 Feb 2004 15:27:46 -0800

Yoshihiro Ohba