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: Alper Yegin <[email-masked]>
Date: Thu, 27 May 2004 22:52:26 -0700

> > > >    at layer 2, this threat is present. It is difficult to 
> > > > protect
> the
> > >

This text just acknowledges discovery may not be protected. By placing
the EP on a choke-point, unauthorized messages can be filtered. It is
not assuming this is always possible, hence it says "it might be
possible for the EP to filter..."

I think we can spell this out, and have some text on location of EP,
what it can and cannot do depending on its location in the topology. 

The access control of the operator depends on where the EPs can be
placed. If there are no EP between the PaCs, they can freely send
packets among themselves. 

Alper