Subject: [Pana] FW: AD review comments on draft-ietf-pana-threats-eval-04.txt

From: Alper Yegin <[email-masked]>
Date: Fri, 21 May 2004 13:47:19 -0700

Please see below for Thomas Narten's review comments on the pana-threats
draft.

- Chairs

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]] 
Sent: Friday, May 21, 2004 8:51 AM
To: [email-masked]; Alper Yegin
Cc: Margaret Wasserman
Subject: AD review comments on draft-ietf-pana-threats-eval-04.txt

Note: for all the review comments, let's discuss today (if necessary),
then  forward to authors/WG.

2004-05-21 review of -04

>    Authentication Server (AS)  
>      
>       An entity that authenticates the PANA client. It may be
co-located  
>       with PANA authentication agent or part of the back-end  
>       infrastructure.  

Here, no distinction is made between Local AS and Home AS. But below:

>      1) PAA and AS: PaC belonging to the same administrative domain as

>         the AS, often needs to use resources provided by PAA that  
>         belongs to another administrative domain. PAA authenticates
the  

Here, it seems it is asume AS is Home AS. 

>      3) PaC and AS: PaC and AS belong to the same administrative
domain  
>         and share a trust relationship. When PaC uses a different
domain  

Same here. Please clarify.

>    It is possible that some of the entities like PAA, AS and EP are

>    co-located. In those cases, it can be safely assumed that there are

>    no significant external threats.  

Doesn't make sense. there is still the PAC-PAA path... Oh, you are
talking only about among the three. Could be more clear (like just
mention you are talking here about communication amoung the three
entities).

>    PANA MUST be able to prevent service theft. In some cases e.g. non-

>    shared links, it is sufficient to provide access control
information  
>    like IP address, MAC address, etc., to EP, which in turn can
prevent  
>    unauthorized users from gaining access to the network by policing
the  
>    packets for matching addresses. In the case of shared links, this  
>    information is not sufficient to prevent service theft. PANA MUST
be  
>    able to bootstrap a shared secret between the PaC and PAA which can

>    be further used to setup a security association (e.g., IPsec)
between  
>    PaC and EP to prevent service theft on shared links.   

Seems wrong. Even in unshared links, if the authorized client
disconnects, and an intruder gets on the link, it can continue using
the DIs.

>    Requirement 9  
>      
>    PANA SHOULD not assume that the PaC has acquired an IP address
before  
>    PANA begins.   

Needs updating.  (also in summary)

>    In environments where the link is shared, this threat is present as

>    any node can pretend to be a PAA. Even if the nodes are
authenticated  
>    at layer 2, this threat is present. It is difficult to protect the

>    discovery process, as there is no a priori trust relationship
between  
>    PAA and PaC. It might be possible for the EP to filter out the  
>    packets coming from PaC that resembles PAA packets and hence this  
>    threat can be prevented in such environments.  

I don't follow. on a shared LAN, its not clear traffic has to go
through the EP. Are there some assumptions going on here?

>    Requirement 1  
>      
>    PANA MUST not assume that the discovery process is protected.
Since,  
>    it is difficult to protect the discovery process, the security-  
>    critical information exchanged during the discovery process SHOULD
be  
>    limited.  

More like discovery should be treated as a hint, and reverified at a
higher layer before accepting as valid. Is the actual requirement that
the PAA  must authenticate itself to the client, to prevent spoofing
during the discovery process?

>        o All the PaCs may be authenticated to the access network at  
>           layer 2 (e.g., 3GPP2 CDMA network) and share a security  
>           association with layer 2 authentication agent (e.g., 802.11

>           [IEEE-802.11] Access point), but still do not trust each  
>           other.  

not sure I follow. In what  way do they not trust each other? What are
the implications, and what does PANA have to do with this?

Nits:

title needs to expand PANA

>    T6.1.1: A malicious node can pretend to be a PAA by sending a
spoofed  
>    advertisement.  

subsubsection headings seem off (all have T in front, and are indented
like normal text)

>    In the following discussion, any reference to link that is not
shared  

s/to/to a/

>      2) PAA and EP: PAA and EP belong to the same administrative
domain.  

s/PAA/The PAA/

>      3) PaC and AS: PaC and AS belong to the same administrative
domain  

s/PaC/The PaC/

NOte: there are multiple places where terms like PAA are used where
you need to use "the PAA", or "a PAA", etc.

>    Some authentication protocols e.g., EAP, has a special message to  

s/has/have/

>    PANA MUST be able to prevent service theft. In some cases e.g. non-

s/e.g./, e.g.,/ (do this throughout probably)

Thomas

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

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 21 May 2004 17:00:00 -0700

> disconnects, and an intruder gets on the link, it can continue using
When an authorized client disconnects, the filters at the enforcement point should
be reset appropriately so that any one using the same DI is not allowed access.
Are you saying that the client was disconnected without the access network (EP/PAA)
knowing ? Could you clarify ?

> Needs updating.  (also in summary)
Okay.

> through the EP. Are there some assumptions going on here?
EP is the policy enforcement point. All data has to go through it. In 802.11, it could
be the AP. In regular LAN, it could be the switch or the router. Perhaps, it is not
explicitly stated. From the requirements document,

Enforcement Point (EP) 
    
        A node on the access network where per-packet enforcement  
        policies (i.e., filters) are applied on the inbound  
        and outbound traffic of client devices. Information such as DI  
        and (optionally) cryptographic keys are provided by PAA per  
        client for constructing filters on the EP. 

Do you think we need explicit clarification  that EP sees all packets or some such thing ?

> during the discovery process?
No. It tries to say that the discovery is just a hint and don't assume that everything
is true. You can't do much about it anyway because you don't have a trust relationship
with the node (PAA) you are talking to.  So, the PANA protocol MUST not assume that the
channel is protected during discovery. Hence, PAA should not include anything that is
sensitive as the PaC has no way of believing it. The other way is to reverify the contents
once you are successfully authenticated so that you know whether you are fooled or not.
If you are fooled, you have to start the process again and this go on forever if the malicious
node can spoof the information. If you never include it in the discovery and include only
when it is safe i.e., after successful authentication protected by MAC, it would be better.
On unshared links, you can trust the information coming from the other end and hence you
may include sensitive information. But, i am not sure whether it is worth it.

> the implications, and what does PANA have to do with this?
To clarify, it says that the PaC's don't trust each other as in a trusted environment
like the office. This means it is a hostile environment to start with. Any node can
act like PAA, any node can spoof packets like you, any node can eavesdrop on you etc.
On such links, PANA should be designed such a way that only the "good" nodes are
authenticated and PaC's authenticate only to the "good" PAA. 

> subsubsection headings seem off (all have T in front, and are indented
I was merely meant it as a way to number it. I can try and indent the following lines
if that would make it look better.

> s/e.g./, e.g.,/ (do this throughout probably)
Ok.

-mohan

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 21 May 2004 17:00:00 -0700

Okay.

Enforcement Point (EP) 

Ok.

-mohan

---

From: Thomas Narten <[email-masked]>
Date: Mon, 24 May 2004 12:24:39 -0400

> When an authorized client disconnects, the filters at the
> enforcement point should be reset appropriately so that any one
> using the same DI is not allowed access.  Are you saying that the
> client was disconnected without the access network (EP/PAA) knowing
> ? Could you clarify ?

Yes. You seem to assume that a disconnection is detectable in a secure
manner. I'm not sure that is always the case. 

> EP is the policy enforcement point. All data has to go through
> it. In 802.11, it could be the AP. In regular LAN, it could be the
> switch or the router. Perhaps, it is not explicitly stated. From the
> requirements document,

> Do you think we need explicit clarification that EP sees all packets

Yes. Also, not all networks can be assumed to have this property
(e.g., ad hoc mode). That is, one may not be able to protect the
shared access link. So I don't really think the document can just
assume this is the case and that having an EP solves all
problems. That wouldn't be completely accurate.

> No. It tries to say that the discovery is just a hint and don't
> assume that everything is true. You can't do much about it anyway
> because you don't have a trust relationship with the node (PAA) you
> are talking to.  So, the PANA protocol MUST not assume that the
> channel is protected during discovery. Hence, PAA should not include
> anything that is sensitive as the PaC has no way of believing
> it. The other way is to reverify the contents once you are
> successfully authenticated so that you know whether you are fooled
> or not.  If you are fooled, you have to start the process again and
> this go on forever if the malicious node can spoof the
> information. If you never include it in the discovery and include
> only when it is safe i.e., after successful authentication protected
> by MAC, it would be better.  On unshared links, you can trust the
> information coming from the other end and hence you may include
> sensitive information. But, i am not sure whether it is worth it.

I think you need to be more clear about what is meant by "sensitive"
information. Sensitive in what sense? That it be provided to a client
that shouldn't get it? That a PaC might be lead astray in a bad way if
it is spoofed?  And what are the dangers if it is misused or
something? I.e., you need to explain what information might be
considered sensitive and why.

> authenticated and PaC's authenticate only to the "good" PAA. 

It would be good to expand on this in the document just a bit.

> if that would make it look better.

It's probably best to use consistent number/indentation.

Thomas

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 24 May 2004 10:22:05 -0700

> manner. I'm not sure that is always the case. 
I am not sure i understood the last sentence. On unshared links, as long as
the disconnect is seen *always*, secure or insecure, the filters will be cleared
so that no nodes can access the network using the same DI. (If it is insecure,
the node that is still connected cannot access it anymore, but this is a different
threat that is later discussed in the document). So, per-packet protection is required
on unshared links only if  the disconnect may not be heard by PAA/EP at all. Is there
a real world scenario where this is possible ?

> problems. That wouldn't be completely accurate.
But this document may not be the right place. PANA assumes that EP
sees all the packets and anything else e.g. ad hoc mode is outside the scope
of PANA. I hope someone else can confirm this.

> considered sensitive and why.
There was one example given in the section about how if you include "authentication
algorithms supported", there might be a possibility of downgrade attack where the
client can end up negotiating a weak one. Isn't that sufficient ? The draft does not
use the word sensitive. It uses "security-related" e.g. authentication methods.

Ok.

> It's probably best to use consistent number/indentation.
Ok, i will keep the text indented.

thanks
mohan

---

From: Thomas Narten <[email-masked]>
Date: Mon, 24 May 2004 13:43:07 -0400

> I am not sure i understood the last sentence. On unshared links, as
> long as the disconnect is seen *always*, secure or insecure, the
> filters will be cleared so that no nodes can access the network
> using the same DI.

Can one assume that such disconnections are _always_ seen? Reliably?
There are cases where one can unplug a mode from one machine to
another and the modem doesn't detect this and drop carrier. In such a
case, the EP wouldn't necessarily detect the switch.

> (If it is insecure, the node that is still connected cannot access
> it anymore, but this is a different threat that is later discussed
> in the document). So, per-packet protection is required on unshared
> links only if the disconnect may not be heard by PAA/EP at all. Is
> there a real world scenario where this is possible ?

This document seems to assume that all of a client's traffic _always_
can be forced through an EP, and thus, if there are filters on the EP,
theft of service and other things can be prevented. I challenge that
assumption. There are shared access links that do not require all
traffic to go through the EP. so service on the local access link can
be "stolen". 

I don't think this changes anything that PANA does. It's more about
being precise and correct in the document in terms of making claims.

> of PANA. I hope someone else can confirm this.

I would assert this is an improper assumption on PANA's part in terms
of evaluating risks and making claims about what PANA can protect
against. 

> There was one example given in the section about how if you include
> "authentication algorithms supported", there might be a possibility
> of downgrade attack where the client can end up negotiating a weak
> one. Isn't that sufficient ? The draft does not use the word
> sensitive. It uses "security-related" e.g. authentication methods.

Going back and rereading the section (and your responses), I am still
unclear on what the stated requirement really should be. Currently, it
says:

>    Requirement 1  
>      
>    PANA MUST not assume that the discovery process is protected. Since,  
>    critical information exchanged during the discovery process SHOULD be  
>    limited.  

I agree with the first part. But the second part (which is a SHOULD)
I'm still unclear about. A fairly general statement is being made
which is hard to understand the implications of. What
"security-critical" information should not be included? and if it is
not, is that a problem for the discovery process?

Thomas

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 24 May 2004 13:48:40 -0700

> case, the EP wouldn't necessarily detect the switch.
Oops! This is T6.3.3 in section 6.3. I have not read this draft
in a long time :-) Section 6.3 discussed about disconnect notification.
Here the attacker is using that to gain access to the unshared link.

>From here, i understand that stating the assumptions would make
it clearer e.g., This document does not discuss about the threats
that arise from direct communication between PaCs. etc. But below,
i am seeing something different..
 
> of evaluating risks and making claims about what PANA can protect
Here, i read it differently. You authenticate to the network before accessing
the network. The service theft is about how to provide access only to
authorized clients ? If the deployment allows for direct communication between
nodes where the network does not have a chance to police the packets,
how can the threat be prevented ? Why should PANA even care about this condition?
It just needs to provide a mechanism so that if used appropriately, the threat
can be prevented. Here, we are only saying that such a bootstrap mechanism
is provided. Depending on how you enforce it you may allow all traffic to
go through the EP e.g. infrastructure mode in 802.11 or police only the traffic
for which you will be billed by the access network etc. So, i am still not understanding
this issue.

> not, is that a problem for the discovery process?
Ok, i can see your concerns.

The main concern is about downgrade attacks where the attacker can
include a different set of information in the advertisement making the client
choose the "weak" element in the set. Having recently discussed this in
the context of PANA, there are several ways this can be approached

1) Include the information only in unshared links where you know it can't be spoofed.

2) Include it in shared links too but verify later whether the information is correct. In this
    approach, it is quite possible that the attacker can always keep feeding the incorrect
    information creating a DoS attack. Also, for you to verify, you need to use an EAP method
    that derives keys so that the information can be protected using MAC.

3) Include it only when it is safe e.g. when it can be protected using MAC. But this
    approach may not be possible always i.e you may have to include at least some information
    in the beginning.

So, perhaps we should leave it to the protocol to decide how this can be done and not
have a requirement. I can add some clarification along the above lines and remove the
requirement. Would that make sense ?

thanks
mohan

---

From: Thomas Narten <[email-masked]>
Date: Tue, 25 May 2004 10:33:39 -0400

> Here, i read it differently. You authenticate to the network before
> accessing the network.

Um, this is not the way I understand it. PANA is supposed to be used
aso in cases where one doesn't authenticate with "the network", e.g.,
at L2.

> The service theft is about how to provide access only to authorized
> clients ? If the deployment allows for direct communication between
> nodes where the network does not have a chance to police the
> packets, how can the threat be prevented ?

It can't (I think we agree on this!) But the threats document should
be honest about that. A general issue I have is that it is not
reasonable to only talk about all traffic going throught the EP and
not discussing the other threats.

> Why should PANA even care
> about this condition?  It just needs to provide a mechanism so that
> if used appropriately, the threat can be prevented. Here, we are
> only saying that such a bootstrap mechanism is provided. Depending
> on how you enforce it you may allow all traffic to go through the EP
> e.g. infrastructure mode in 802.11 or police only the traffic for
> which you will be billed by the access network etc. So, i am still
> not understanding this issue.

> include a different set of information in the advertisement making
> the client choose the "weak" element in the set. Having recently
> discussed this in the context of PANA, there are several ways this
> can be approached

> 2) Include it in shared links too but verify later whether the
> information is correct. In this approach, it is quite possible that
> the attacker can always keep feeding the incorrect information
> creating a DoS attack. Also, for you to verify, you need to use an
> EAP method that derives keys so that the information can be
> protected using MAC.

> 3) Include it only when it is safe e.g. when it can be protected
> using MAC. But this approach may not be possible always i.e you may
> have to include at least some information in the beginning.

> So, perhaps we should leave it to the protocol to decide how this
> can be done and not have a requirement. I can add some clarification
> along the above lines and remove the requirement. Would that make
> sense ?

Yes. Maybe the requirment should be that PANA needs to assume the
discovery process is unreliable and subject to vulnerabilities, and
that PANA itself needs to take approriate steps to mitigate these
concerns?

Thomas

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 25 May 2004 10:37:42 -0700

> aso in cases where one doesn't authenticate with "the network", e.g.,
I meant to say "You authenticate to the network using PANA before accessing
the network".

> be honest about that. 

Ok, we can clarify this in the document.

>A general issue I have is that it is not
But we are talking about threats that relate to PANA protocol itself.
Service theft is post-PANA that has some requirements on PANA itself
and that's why it has been documented. In the miscellaneous attacks sections,
it does talk about some general attacks. Could you be specific about what
else can be documented ?

> that PANA itself needs to take approriate steps to mitigate these
Ok, i will add this to the requirement.

thanks
mohan

---

From: Alper Yegin <[email-masked]>
Date: Thu, 27 May 2004 23:00:34 -0700

> > disconnects, and an intruder gets on the link, it can continue using

To be on the safe side, I think we should also cover the case where
disconnection may not be detected. Let's not limit the cryptographic
protection case (e.g., IPsec) to only shared links. Unshared (e.g.,
point-to-point physically secured) links can also resort to using
per-packet ciphering if there is a chance that an already authorized
client is somehow replaced by an unauthenticated client.

Alper