Subject: pana-threats WG LC comments

From: Alper Yegin <[email-masked]>
Date: Wed, 30 Apr 2003 11:40:37 -0700

Hello,

I'm forwarding Asokan's comments on PANA security threats draft. Please see
below....

Alper

Review of draft-ietf-pana-threats-eval-03.txt
April 30, 2003

Section 4
- para 1: this text is unclear in a couple of places
  - "trust operators .. to provide THE service"
    What service is it?  Network access?  Some other services?
    Which nodes?  Client nodes only, or other network nodes too?
  - "not trust other nodes.. e.g., ... Hotel, Airport"
    These are not nodes. Was the idea that the access points in these
    places may not be trusted?
  - "not trust relationship.. [but] belief about how the nodes ...
     behave in the future"

    This text is contradictory.  If the relationship is not about
    trust, it cannot be called "trust relationship".

  Suggestions
  - since you have already defined your terminology, it would be good
    to use those defined terms like PaC and AS, rather than a generic
    term like "nodes"

  - Perhaps the intended message of this paragraph is something like
    this: 
    - PANA is intended to be used in an environment where there is no
      priori trust relationship or security association between PaC
      and nodes in the access zone like PAA and EP.

- para 2: bullet 2
  change
    "access network at layer 2 (3GPP2 CDMA network)"
  to
      "access network at layer 2 (e.g., 3GPP2 CDMA network)"

Section 5
- The title says "Trust relationships", but the only reference to trust
  relationships is in the last para (about PaC and EP).  I think you
  should
  - list the pairs of nodes between which a priori trust relationship
    is assumed (i.e., trust assumption)
    e.g., PaC and AS, PAA and EP, PAA and AS
  - list the initial security associations required to exist before
    PANA begins.
    e.g., PaC and AS, PAA and EP (maybe), PAA and AS (either static or
          derived using the AAA infrastructure)

- last para
  change
    key derivation
  to
    key establishment
  key may be derived, or transported (chosen by one party and sent to
  the other)

- PANA also MUST result in key establishment between PaC and PAA
  (Requirement 2)

Section 6.1
- Threat 6.1.1 is ok.  But it is not clear how that implies
  "information exchange .. SHOULD be limited".  For e.g., discovery
  process may list 100s of potential PAA addresses.  If they are all
  equal, there is no _security_ reason to limit the number of
  candidate PAAs.

  Suggestions for requirement:
  - security-criticical choices (e.g., authentication methods to be
    agreed between PaC and PAA) SHOULD be limited.

Section 6.2.1
- Protecting Success or Failure indications
  If this requirement is motivated by EAP, maybe it should be
  mentioned.  Better still, generalize the requirement so that it
  is not specific to one authentication framework.

  In a more general sense, the requirement is not just about
  success/failure indications, but about any "control" message
  (success/failure, disconnect/revoke, reauthentication requests etc.)

- change "methods that can derive keys" to "methods that result in
  keys"?

- question: is it really the intent to protect failure messages, too?
  (they can't be protected using session keys resulting from
   authentication methods)

- first paragraph on page 7: if the link is not shared then either you
     assume that the link is physically secure, or it is not necessary
     to differentiate it from a shared link.
  In this case, this whole paragraph can be replaced by the sentence
     that you use in pretty much every other threat "If the link is
     not a shared medium, then this threat is absent"

Section 6.2.2

- You have to clarify when MitM vulnerability exists.  Just using a
  compound authentication method doesn't automatically lead to the
  vulnerability. For example, PANA may use a tunnel to protect an
  eavesdropper in the PaC-PAA path from listening in on information
  exchanged by the inner authentication method.  This doesn't lead to
  a MitM attack.  MitM shows up only when the tunnel keys are used as
  session keys between PaC and some other entity (PAA or EP)
  
- So, before you talk about MitM, you should first decide whether it
  is a PANA security requirement to use a tunneling method for the
  purpose of deriving session keys between PaC and PAA.

Section 6.2.4
- "protect the device identifier" is too general:  What you mean here
  is something like "protect the integrity of the binding of the
  device identifier to the authenticated session"

Section 6.3
- See comment on Section 6.2.1.  Requirements 2 and 6 are related.

Section 6.4
- See comment on Section 6.2.4.  Requirements 5 and 7 are related (5
  is a special case of 7)

- The basic requirement is not really about "generating access control
  information" but that PANA must make sure that the credentials to be
  used in authorizing packets through the EP (device identifier, IPsec
  AH key etc.) are securely bound to the authenticated session.  In
  the case of device identifier, the binding is integrity protection.
  In the case of IPsec AH key, the binding is to ensure that PANA
  results in a secret session key to be used between PaC and EP.

Section 6.5
- point 2: reference to "public key computation" also seems to presume
  specific solution techniques.  Suggestion: replace "public key
  computation" by "computationally intensive operations"

Section 6.6
- change "should not" to "SHOULD NOT"