Skip to main content

Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements
RFC 4016

Revision differences

Document history

Date Rev. By Action
2015-10-14
07 (System) Notify list changed from basavaraj.patil@nokia.com, Alper.Yegin@samsung.com, mohanp@sbcglobal.net to (None)
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Steven Bellovin
2005-04-07
07 Mark Townsley Shepherding AD has been changed to Thomas Narten from Mark Townsley
2005-04-05
07 Brian Carpenter Shepherding AD has been changed to Mark Townsley from Brian Carpenter
2005-03-26
07 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2005-03-26
07 Amy Vezza [Note]: 'RFC 4016' added by Amy Vezza
2005-03-26
07 Amy Vezza Shepherding AD has been changed to Brian Carpenter from Thomas Narten
2005-03-18
07 (System) RFC published
2004-10-01
07 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-09-30
07 Amy Vezza IESG state changed to Approved-announcement sent
2004-09-30
07 Amy Vezza IESG has approved the document
2004-09-30
07 Amy Vezza Closed "Approve" ballot
2004-09-30
07 Thomas Narten State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Thomas Narten
2004-09-30
07 Thomas Narten [Note]: '2004-09-30: Last Discuss cleared, ready for approval.' added by Thomas Narten
2004-09-28
07 Steven Bellovin [Ballot Position Update] Position for Steve Bellovin has been changed to No Objection from Discuss by Steve Bellovin
2004-09-08
07 Thomas Narten [Note]: '2004-09-08: Sent followup to Bellovin to see if version -07 addresses
his concerns.
' added by Thomas Narten
2004-08-09
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-08-09
07 (System) New version available: draft-ietf-pana-threats-eval-07.txt
2004-06-25
07 (System) Removed from agenda for telechat - 2004-06-24
2004-06-24
07 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2004-06-24
07 Russ Housley
[Ballot comment]
Please update the Abstract so that it starts with the point of
  the document, rather than the point of the working group. …
[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.
2004-06-24
07 Russ Housley [Ballot Position Update] New position, Undefined, has been recorded for Russ Housley by Russ Housley
2004-06-24
07 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2004-06-24
07 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2004-06-24
07 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2004-06-23
07 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2004-06-23
07 Ted Hardie
[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 …
[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
2004-06-23
07 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Undefined by Ted Hardie
2004-06-23
07 Ted Hardie
[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 …
[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.
2004-06-23
07 Ted Hardie [Ballot Position Update] New position, Undefined, has been recorded for Ted Hardie by Ted Hardie
2004-06-23
07 Steven Bellovin
[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 …
[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.
2004-06-23
07 Steven Bellovin [Ballot Position Update] New position, Discuss, has been recorded for Steve Bellovin by Steve Bellovin
2004-06-23
07 Thomas Narten [Ballot Position Update] New position, Yes, has been recorded for Thomas Narten
2004-06-23
07 Thomas Narten Ballot has been issued by Thomas Narten
2004-06-23
07 Thomas Narten Created "Approve" ballot
2004-06-23
07 (System) Ballot writeup text was added
2004-06-23
07 (System) Last call text was added
2004-06-23
07 (System) Ballot approval text was added
2004-06-23
07 Thomas Narten [Note]: 'Red Team Document' added by Thomas Narten
2004-06-17
06 (System) New version available: draft-ietf-pana-threats-eval-06.txt
2004-06-17
07 Thomas Narten State Changes to IESG Evaluation from AD Evaluation::AD Followup by Thomas Narten
2004-06-17
07 Thomas Narten Placed on agenda for telechat - 2004-06-24 by Thomas Narten
2004-06-17
07 Thomas Narten Note field has been cleared by Thomas Narten
2004-06-15
07 (System) Sub state has been changed to AD Follow up from New Id Needed
2004-06-15
05 (System) New version available: draft-ietf-pana-threats-eval-05.txt
2004-06-02
07 Thomas Narten State Change Notice email list have been change to basavaraj.patil@nokia.com, Alper.Yegin@samsung.com, mohanp@sbcglobal.net from ,
2004-06-02
07 Thomas Narten State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Thomas Narten
2004-06-02
07 Thomas Narten
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: …
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
2004-06-02
07 Thomas Narten [Note]: '2004-05-21: AD review comments sent to list, revised ID needed, then to IESG' added by Thomas Narten
2003-07-28
07 Thomas Narten Shepherding AD has been changed to Narten, Thomas from Nordmark, Erik
2003-05-21
07 Erik Nordmark Intended Status has been changed to Informational from Proposed Standard
2003-05-21
07 Erik Nordmark State Changes to AD Evaluation from Publication Requested by Nordmark, Erik
2003-05-21
07 Natalia Syracuse Draft Added by Syracuse, Natalia
2003-05-19
04 (System) New version available: draft-ietf-pana-threats-eval-04.txt
2003-04-14
03 (System) New version available: draft-ietf-pana-threats-eval-03.txt
2003-03-05
02 (System) New version available: draft-ietf-pana-threats-eval-02.txt
2003-01-13
01 (System) New version available: draft-ietf-pana-threats-eval-01.txt
2002-10-22
00 (System) New version available: draft-ietf-pana-threats-eval-00.txt