Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements
draft-ietf-pana-threats-eval-07

[Ballot comment]
Please update the Abstract so that it starts with the point of
  the document, rather than the point of the working group. I
  propose:

    This document discusses the threats to protocols used to carry
    authentication for IP network access. The security requirements
    arising out of these threats will be used as additional input to
    the PANA (Protocol for Carrying Authentication for Network Access)
    Working Group for designing the IP-based network access
    authentication protocol.

[Ballot comment]
No further blocking objections.  Two smaller points:

The draft uses co-located to mean something far beyond "in the same place",
and I'd suggest expanding on the term or looking for another that covers the
ground a bit better.

The "service theft" threat implies a threat to other systems which
is not necessarily present in other threats--someone taking over
another's IP address and MAC may also be authorized by weak
schemes at upper layers that rely on those; further, it opens the
possibility of attempts to take over other existing flows.  This
draft doesn't need to cover that, but some text pointing to the
possibility might be useful

[Ballot comment]
The draft uses co-located to mean something far beyond "in the same place",
and I'd suggest expanding on the term or looking for another that covers the
ground a bit better.

[Ballot discuss]
The document is full of statements about the relative security of unshared links compared with shared links (such as Ethernet).  While this is true from an IP perspective, there are many attacks at lower layers.  The Security Considerations section should note that against some threats, *all* media should be considered shared.  Note that this is especially true because of tunneling -- what looks like a dial-up link may, in fact, be tunneled over an IP backbone to a remote NAS -- and because of the PWE3 effort.  I'm not asking this group to solve those problems, but the security considerations section needs to mention them.

From: Thomas Narten
To: Basavaraj.Patil@nokia.com, Alper Yegin
cc: Margaret Wasserman
Date: Fri, 21 May 2004 11:50:42 -0400
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