Subject: Comments on draft-ietf-pana-requirement-00.txt

From: David Reeder <[email-masked]>
Date: Thu, 7 Mar 2002 19:05:50 -0500

I am new to the mailing list, apologies if the following issues have
already been discussed or resolved.  Issues concern the relationship
between PANA protocol and whichever protocol it encapsulates.  

[NOTE -- Written about the same time as George's post yesterday, I think
these issues provide some grounding for chosing EAP.  Have also posted
a note to ietf-ppp which raises some of the issues in the discussion
after George's post.]

If PANA WG chooses not to encapsulate another protocol, and to develop
its own independent protocol, then really only the first issue
(mostly a docuentation issue?) is relevant.

I realize that PANA may or may not adopt EAP as a means to bundle the
various problems of authentication given in the charter.
Nonetheless, it seems that it is a compelling alternative, and for
simplicity my comments assume that PANA encapsulates EAP.  I think,
however, if the hard details were abstracted away, EAP could be
replaced with any encapsulated Protcol-X and similar considerations
should apply to it.

ISSUE #1 -- Document inconsistency with regard to key management:

  The text in Section 4.4 ("Performance") about setting up local
  security associations (SAs) contradicts the "hands-off" to security
  approach explicitly given in Section 4.1.1 ("Authentication") which
  reads: "PANA MUST NOT define new security protocols or mechanisms."

ISSUE #2 -- PANA requirements should not be stronger than EAP:

  To specify requirements that govern the details of authentication
  via some encapsulated protocol such as EAP, is to split
  functionality which should be specified in a single protocol and
  operate in a single layer sub-system.

  In the particular case of PANA and EAP, details such as replay
  protection or details such as reliable delivery should be bundled
  as changes to the encapsulated protocol as many will have important
  interactions with other protocol state and must be centralized to ease
  the task of security assessment.

  To follow this strictly would require that all issues of security
  and reliability be deferred to the EAP specification.

ISSUE #3 -- PANA should specify all details of its transport layer, 
              EAP should be transport agnostic.

  EAP discusses transport issues obliquely in Section 3
  ("Media-specific issues") of draft-ietf-pppext-rfc2284bis-02.txt.
  It is not concerned with the type of transport, but rather with the
  interactions between EAP exchanges over a potentially lossy
  connection and the behavior or choice of the next-stage protocol.
  Specifically, EAP is concerned with how the Peer may understand
  that the Authenticator has responded at the end of an
  authentication exchange if the response packet should be lost.  For
  example, EAP indicates that during a PPP exchange in which EAP is
  used, if the Success Reply packet is lost, then the presence of an
  NCP packet may be used to indicate that Success was granted by the
  Authenticator.

  This detail about transport protocol interaction seems out of scope
  for EAP.  Further, any new transport that PANA defines should have
  some consideration of interactions with next-stage protocols.  At
  the very least PANA should indicate when details of such
  interaction need not be defined, eg loss of Request or Reply
  packets simple causes fallback to retry or restart an authentication
  exchange.

david

..........................................................................
  David Reeder   908/947-7075                     804a 2990 2490 47c3 8ef1  
  <[email-masked]>                           23be 39ce d1f5 56c0 a5c5

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Fri, 8 Mar 2002 16:39:10 -0800

David,

>   reads: "PANA MUST NOT define new security protocols or mechanisms."

The draft says it must not "define" such methods, but can "use" [an already
defined one of] them. So, I don't think there is inconsistency.
The task for PANA is to pick a security mechanism/protocol
which can setup local SAs.

alper