Subject: RE: pana-threats WG LC comments

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 1 May 2003 14:56:13 -0700

Asokan,

Thanks for the review. Comments below.
> 
> 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?

It is the network access that I was referring to here. And the nodes
being referred to are the PaCs.

>   - "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?

The nodes here refer to PaCs. 

I have been mostly biased by the discussions in the SEND WG
(draft-ietf-send-psreq-03.txt). 

Could you tell me what you meant above when you used the word "trusted"
?
I was trying to somehow differentiate this from a ad-hoc
network, where none of the nodes trust each other. Here at least,
the PaC's belief about a PAA and other PaCs are different.
I am really wondering how useful this distinction is as any PaC could
spoof like a PAA.

>   - "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".

"Trust relationship" really meant pre-configured authentication
information i.e none of the nodes have any pre-configured authentication
information about each other.
  
> 
>   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.
> 
This one sounds good to me. Perhaps less confusing than my text.

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

> 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)
> 
Ok.

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

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

> 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.

This is what I was trying to say. This brings the point more clearly.

> 
> 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.)
> 
I think I mentioned this in replay attacks but it never came out
in the requirements.

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

> - question: is it really the intent to protect failure messages, too?
>   (they can't be protected using session keys resulting from
>    authentication methods)
There was quite a bit of discussion in the EAP working group sometime
back. If there is a EAP method specific failure, wouldn't that override
the EAP failure itself. Again, this document itself does not talk about
which failure it is. When I read the latest EAP document, it is still
not clear to me. I will let others comment on this.
> 
> - 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"
> 
Yeah, that would make it more consistent.

> 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

Correct. But the text does not seem to say that. It only says that
"MiTM attack exists if compound methods (which is defined as either the
sequence of methods one after another or methods are tunneled
inside a one-way authenticated tunnel) are not cryptographically
bound". Do you think it captures the basic idea ?

>   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)
>   
I am not sure I understood all of the last sentence. Could you elaborate
?

> - 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.
> 
We have had some discussions in the past regarding this. It was decided
that PANA will not limit any specific EAP methods.

> 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"
> 
Correct.

> Section 6.3
> - See comment on Section 6.2.1.  Requirements 2 and 6 are related.
> 
Agreed. But it is also possible that when you leave the network, you
can do another auth like exchange that says "I am disconnecting".

> Section 6.4
> - See comment on Section 6.2.4.  Requirements 5 and 7 are related (5
>   is a special case of 7)
> 
Do you think it is still useful to state them separately ?

> - 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.
> 
Agreed. This section has been modified quite a few times :-) I can
adopt your text above.

> 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"

okay.

> 
> Section 6.6
> - change "should not" to "SHOULD NOT"
>   
okay.

thanks
mohan