Subject: [Pana] review of the pana protocol

From: Jari Arkko <[email-masked]>
Date: Wed, 04 Feb 2004 11:24:29 +0200

Hi,

I have read draft-ietf-pana-pana-03b. You can find my comments
from http://www.arkko.com/publications/pana/pana_03b_review.txt

For your convenience, the overall comments are copied below:

       In general, I was quite positively surprised by this
       document. The basic design is sound as far as I can see, and in
       some aspects better than competing link layer designs. I did
       have quite many questions and technical issues, however, so we
       should work to address them.

       Note: My review comments have been marked like this, and
       classified either as Substantial, Technical, Editorial, Comment,
       or Question.

       The substantial issues I identified are listed also below:

       - "key generation mandatory"

         Consider requiring only key generating EAP methods, as then
         the security properties of the PANA protocol are much better
         and can be described in a much easier way. Note that you do
         NOT have to use data protection for the benefits to be
         realized. State synchronization issues are avoided as you can
         confirm success with the MACs in the Bind Request and
         Answer. Or termination can be done securely. Note: EAP-TLS,
         EAP-SIM, EAP-AKA, EAP-Archie, EAP-IKEv2, EAP-MSCHAPV2, and all
         tunnel methods provide keys. I have understood that for all
         legacy EAP methods that do not provide keys, there exists
         newer variants that do and which can still reuse the old
         credentials.

       - "Details of double authentication"

         Perhaps its just me, but I did not find all the details
         regarding the use of two (NAP and ISP) authentications. Is
         this supported or not? Are they performed in sequence? Does it
         look like a re-authentication, or do you provide a bit
         somewhere that indicates whether this EAP run relates to the
         NAP or the ISP authentication? Is there a PANA Bind Request -
         Answer pair in between or not?

	Is it really necessary to provide to separate authentications?
	Traditionally, NAP - ISP separation has been achieved through
	roaming relationships in AAA, i.e., you just authenticate to
	the access network but they forward the AAA transaction to the
	home network.

	Why is there no problem with the mitm attacks in the PANA
	authentication sequences, as there are in other EAP sequencing?

       - "Additional discovery information?"

         I'm not sure if there is a need to provide some additional
         information in the discovery phase. For instance, is there a
         need to identify the NAS/PAA in a scenario where the NAS/PAA
         has multiple interfaces and multiple addresses? Knowing you
	are still connected to the same NAS might help future handoff
	designs.

       - "Cookie mandatory"

         I would like the inclusion of the cookie to in the start
         exchange to be mandatory.

       - "Client cookie useful?"

         Would it be useful for the client to provide its own cookie as
         well, such that for solicited PSRs, the client's cookie would
         be copied back. This would cost very little, but protect the
         client against blind PAA spoofing attempts.

       - "AAA routing based on NAI vs. ISP choice"

         Section 4.2 claims that AAA routing is based on the ISP
         choice.  I believe the first hop decision can be based on
         this, but further on in the network it must be based on the
         NAI (unless you revise AAA protocols).

       - "PSR retransmission strategy"

         In Section 4.2 I also had a possible issue with retransmission
         strategy in case PSR is lost. The document seems to say that
	PSRs are never retransmitted but at the same time the PDIs
	are silently discarded. This could lead to a deadlock.

         (It would be very useful to see a state machines filled in.)

       - "Fast-reauthentication and authorization issues"

         I have reservations about the inclusion of the fast
         re-authentication scheme in the base PANA document. There are
         a number of security issues at the system level when you try
         to do this. See draft-ietf-eap-keying-01.txt, Sections 1.4 and
         1.4.1 in particular for some examples.

         Note also that many EAP methods provide fast re-authentication.

       - "TTL and other IP layer details"

         I think you should specify in more detail the contents of the
         IP and UDP headers associated with PANA messages. For
         instance, the document implies that TTL can be used to limit
         the ability of attackers to send PANA messages, but I did not
         find a place where the document would actually require setting
         or checking the TTL. Or did I miss it?

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

---

From: Alper Yegin <[email-masked]>
Date: Wed, 04 Feb 2004 14:55:38 -0800

Hi Jari,

Thank you very much for this detailed review. It is very helpful.

Please see my brief response below. We will open new issues in the PANA
tracking system, so that we can trace the relevant discussions and
decisions.

>        newer variants that do and which can still reuse the old

I agree that making this assumption would simplify the PANA specification.
But as an EAP lower-layer, I don't think we can do that. We should be able
to carry EAP which might carry any EAP method. As long as there are such
legacy methods and networks using them, making key generation mandatory
would appear as a limitation of the PANA.

>        Answer pair in between or not?

This says the text is not sufficient. We shall open an issue on this and try
to clearly answer your questions.

> the access network but they forward the AAA transaction to the

This was discussed during the requirements stage. Some (DSL) operators
indicated that separately authenticating the user to the NAP and ISP is a
desirable feature. This helps them provide differentiated services through
the user's subscription to both service providers. This is an enhancement to
the current picture as you described.

> authentication sequences, as there are in other EAP sequencing?

Along with revising the text, we should also analize this.

> are still connected to the same NAS might help future handoff

This sounds like a useful feature. I'd recommend we open an issue and
investigate this. It can assist movement detection.

>        client against blind PAA spoofing attempts.

OK, we shall open an issue and track this.

>        NAI (unless you revise AAA protocols).

Another issue to open (at least to clarify the text).

> are silently discarded. This could lead to a deadlock.

Another issue to open.

>        (It would be very useful to see a state machines filled in.)

We have on-going state machine work.
http://danforsberg.info:8080/pana-issues/issue28 .

>        Note also that many EAP methods provide fast re-authentication.

I think we should open an issue and investigate this.

>        or checking the TTL. Or did I miss it?

Yes, this is missing. We can clarify this in the text (new issue).

Thank you.

Alper

---

From: Alper Yegin <[email-masked]>
Date: Wed, 04 Feb 2004 14:55:38 -0800

Hi Jari,

Another issue to open.

Thank you.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 04 Feb 2004 18:07:56 -0800

Thanks Jari for your detailed review.  

I first try to resolve Editorial issues first, so that the editorial changes 
are quickly reflected to the upcoming -03 draft.  

Your 18 editorial comments (as well as 3 "Comment" comments) are all
valid.  I have one question to Jari on the definition of MSK (please
see my comments below).

-------
   Currently there is no standard network-layer solution for
   authenticating clients for network access.
   [I-D.ietf-pana-usage-scenarios] describes the problem statement that
   led to the development of PANA.

   Scope of this working group is identified as designing a link-layer

JARI: (Editorial) s/working group/work/?

OHBA: OK.

-----
   agnostic transport for network access authentication methods. PANA
   Working Group has identified EAP [RFC2284] as the payload for this
   protocol and carrier for authentication methods.

JARI: (Editorial) Maybe replace with "The Extensible
      Authentication Protocol (EAP) [RFC2284bis] provides such
      authentication methods."

OHBA: OK.

----
   Various environments and usage models for PANA are identified in the
   [I-D.ietf-pana-usage-scenarios] Internet-Draft. Potential security
   threats for network-layer access authentication protocol is discussed

JARI: (Editorial) s/is/are/

OHBA: OK.

-----
   This Internet-Draft makes an attempt for defining the PANA protocol
   based on the other drafts discussed above. Special care has been
   given to ensure the currently stated scope is observed and to keep
   the protocol as simple as possible. The current state of this draft
   is not complete, but it should be regarded as a work in progress.
   The authors made effort to capture the common understanding developed
   within the working group as much as possible. The design choices
   being made in this draft should not be considered as cast in stone.

JARI: (Editorial) Yes, but this is assumed for I-Ds anyway. You could
      probably remove the paragraph.

OHBA: I agree.  Let's remove it.

-------
   The definition of the terms PANA Client (PaC), PANA Authentication
   Agent (PAA), Enforcement Point (EP) and Device Identifier (DI) can be
   found in [I-D.ietf-pana-requirements].

JARI: (Editorial) If its just 4 definitions, I would prefer them to
      be copied here too.

OHBA: Yes, it is better.  So I would replace the above paragraph with
the following text (copied from [I-D.ietf-pana-requirements]):

"
   PANA Client (PaC)
                                                                                
        The client side of the protocol that resides in the host device
        which is responsible for providing the credentials to prove its
        identity for network access authorization.
                                                                                
   Device Identifier (DI)
                                                                                
        The identifier used by the network as a handle to control and
        police the network access of a client. Depending on the access
        technology, this identifier might contain any of IP address,
        link-layer address, switch port number, etc. of a connected
        device.

   PANA Authentication Agent (PAA)
                                                                                
        The access network side entity of the protocol whose
        responsibility is to verify the credentials provided by a PANA
        client and grant network access service to the device
        associated with the client and identified by a DI.
                                                                                
   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.
"

OHBA: Also, I will add the following definitions here to reflect your
other comments:

   Network Access Provider (NAP) 

        A service provider that provides physical and link-layer
        connectivity to an access network it manages.

   Master Session Key (MSK)

        Keying material (at least 64 octets) that is derived between
        the EAP client and server and exported by the EAP method.
"

OHBA: Is the definition (copied from draft-ietf-eap-keying-01.txt) of
MSK correct?  I am a bit confused about the distinction between MSK
and AAA-Key.

------- 
3. Protocol Overview
                                                                                
   The PANA protocol involves two functional entities namely the PaC and
   the PAA. The EP, mentioned in the context with PANA, is a logical
   entity. There is, however, the option that the EP is not physically
   co-located with the PAA. In case that the PAA and the EP are
   co-located only an API is required for intercommunication instead of
   a separate protocol. In the case where the PAA is separated from the
   EP, a separate protocol will be used between the PAA and the EP for
   managing access control. The protocol and messaging between the PAA
   and EP for access authorization is outside the scope of this draft
   and will be dealt separately.

JARI: (Editorial) For the clarity of presentation, maybe you should
      talk about the EP case later, and not start with it.

OHBA: I agree.  How about re-arranging the contents of section 3 like:

"
3. Protocol Overview

   The PANA protocol involves two functional entities namely the PaC
   and the PAA.  The protocol resides above the transport layer and
   the details are explained in Section 4.  
                                                                                
   The placement of the entities used in PANA largely depends on a
   certain architecture.  The PAA may optionally interact with a AAA
   backend to authenticate the user (PaC).  The EP, mentioned in the
   context with PANA, is a logical entity.  There is, however, the
   option that the EP is not physically co-located with the PAA. 
   In case that the PAA and the EP are co-located only an API is
   required for intercommunication instead of a separate protocol. In
   the case where the PAA is separated from the EP, a separate
   protocol will be used between the PAA and the EP for managing
   access control.  The protocol and messaging between the PAA and EP
   for access authorization is outside the scope of this draft and
   will be dealt separately.  Figure 1 illustrates the interactions in
   a simplified manner:
                                                                                
           PaC                   EP            PAA           AAA
           ---                   ---           ---           ---
                                                                                
                         PAA Discovery
            <---------------------o------------> (1)
                      PANA Authentication       AAA interaction
            <----------------------------------><------------> (2)
                                                                                
                                     Authorization
                                  <-------------  (3)
                                                                                
                        Figure 1: PANA Framework

(End of Section 3)

------
   o  Session-Id AVP: contains the session identifier value.

   o  Session-Lifetime AVP: contains the duration of authorized access.

   o  Failed-AVP: contains the offending AVP that caused a failure.

   o  NAP-Information AVP, ISP-Information AVP: contains the information
      on a NAP and an ISP, respectively.

JARI: (Editorial) NAP term not yet defined. Add to defs section.

OHBA: OK.

   o  Key-Id AVP: contains an MSK identifier.

JARI: (Editorial) MSK not yet defined. Add to defs section.

OHBA: OK.

-----
   unicast.  PaC MAY use unspecified IP address for communicating with
   PAA.
                                                                                
JARI: (Comment) I think I have said it in the past that I have
      reservations about the use of the unspecified address. But I
      forget what the resolution of this was. Reading on...
                                                                                
OHBA: The use of unspecified address will be removed in -03.
------
      PANA_MAC_KEY = The first N-bit of
                     HMAC_SHA1(MSK, ISN_pac | ISN_paa | Session-ID)

JARI: (Editorial) s/N-bit/N bits/

OHBA: OK.
------

   where the value of N depends on the integrity protection algorithm in
   use, i.e., N=128 for HMAC-MD5 and N=160 for HMAC-SHA1.

   The length of MSK MUST be N-bit or longer.  See Section 4.1.6 for the

JARI: (Editorial) s/N-bit/N bits/

OHBA: OK.

---------
      imply the PAA being stateful? Most often the initial EAP request
      is an identity request, which has just one potentially changing
      field, the EAP level sequence number. However, this sequence
      number could presumably be the same random number for all
      clients connecting around the same time, since the PANA
      sessions, if they are established, are identified by the device
      identifiers.

   peer or EAP (pass-through) authenticator."

JARI: (Editorial) Extra quote at the end.

OHBA: OK, I'll remove it.

--
   The reason for termination is indicated in the Termination-Cause AVP.
   When there is an established PANA SA established between the PaC and
   the PAA, all messages exchanged during the termination phase MUST be
   protected with a MAC AVP.  When the sender of the PANA-
                                                                                
JARI: (Comment) Great, so this is better than 802.11i!
                                                                                
OHBA: Yes!!  And PANA with bootstrapping WPA/IEEE 802.11i PSK mode can
improve wireless LAN security.  You may be interested in
pana-framework draft which will be submitted in a couple of days
(there is a PANA WLAN example in the draft).
--
4.12 PaC Implications
                                                                                
   o  PaC state machine. [TBD]

4.13 PAA Implications
                                                                                
   o  PAA state machine. [TBD]

JARI: (Comment) Experience from EAP indicates that protocol should
      not be considered complete until the state machine exists.
                                                                                
OHBA: I agree, and we are working on it now.
--
   PANA relies on EAP and the EAP methods to provide a session key in
   order to establish a PANA security association. An example of such a
   method is EAP-TLS [RFC2716], whereas EAP-MD5 [RFC2284] is an example
   of a method that cannot create such keying material. The choice of
   EAP method becomes important, as already discussed in the next
   section.

JARI: (Editorial) s/already//

OHBA: OK.

--
   encryption of IP packets. Fresh and unique session key derived from
   the EAP method is still insufficient to produce an IPsec SA since
   both traffic selectors and other IPsec SA parameters are missing.
   The shared secret can be used in conjunction with a key management
   protocol like IKE [RFC2409] to turn a simple shared secret into the
   required IPsec SA. The details of this mechanism is outside the scope
   of PANA protocol [I-D.ietf-pana-ipsec], PANA provides bootstrapping
   functionality for such a mechanism by carrying EAP methods that can
   generate initial keying material.

JARI: (Editorial) I think the last sentence would be clearer as "The details
      of such mechanisms are outside the scope of this document and can
      be found in [I-D.ietf-pana-ipsec]."

OHBA: Yes, that is clearer.  I'll change the sentence as such.

-------
   Using network-layer ciphers should be regarded as a substitute for
   link-layer ciphers when the latter is not available. IKE involves
   several message exchanges which can incur additional delay in getting
   basic IP connectivity for a mobile device. Such a latency is

JARI: (Comment) And additional header overhead.

OHBA: OK, I'll modify the sentence to:

   "IKE involves
   several message exchanges which can incur additional delay and
   header overhead in getting basic IP connectivity for a mobile device."

--
   the EAP method allows session key derivation and that the generated
   session key has a good quality. For further discussion about the
   importance of the session key generation refer to the next subsection
   (d) about compound authentication. The session key available for the
   PaC is established as part of the authentication and key exchange
   procedure of the selected EAP method. The PAA obtains the session key
   via the AAA infrastructure (if used). Security issues raised with
   this session key transport are described in
   [I-D.walker-aaa-key-distribution].

JARI: (Editorial) And draft-ietf-eap-keying?

OHBA: Yes, it should be draft-ietf-eap-keying.

--
   g) Liveness test

   Network access authentication is done for a very specific purpose and
   often charging procedures are involved which allow restricting
   network resource usage based on some policies. In mobility

JARI: (Editorial) s/mobility/mobile/

OHBA: OK.

----
   [I-D.ietf-pana-requirements]
              Yegin, A. and Y. Ohba, "Protocol for Carrying
              Authentication for Network Access  (PANA)Requirements",
              draft-ietf-pana-requirements-07 (work in progress), June
              2003.

JARI: (Editorial) If you move a couple of terms to this draft, you
      can make this reference informational.

OHBA: I'll move it to the informative references section.
----
   [I-D.ietf-aaa-eap]
              Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
              Authentication Protocol (EAP) Application",
              draft-ietf-aaa-eap-03 (work in progress), October 2003.

JARI: (Editorial) Strictly speaking, why is this normative? I don't think
      you require the backend AAA protocol to be Diameter, it could be
      RADIUS too, right? Are you copying AVPs or what?

OHBA: You are right.  Dimemeter EAP application is not mandatory for
PANA to work.  I'll move it to the informative references section.

   [I-D.irtf-aaaarch-handoff]
              Arbaugh, W. and B. Aboba, "Experimental Handoff Extension
              to RADIUS", draft-irtf-aaaarch-handoff-03 (work in
              progress), October 2003.
                                                                                
   [I-D.orman-public-key-lengths]
              Orman, H. and P. Hoffman, "Determining Strengths For
              Public Keys Used For Exchanging Symmetric  Keys",
              draft-orman-public-key-lengths-05 (work in progress),
              January 2002.
                                                                                
   [I-D.puthenkulam-eap-binding]
              Puthenkulam, J., "The Compound Authentication Binding
              Problem", draft-puthenkulam-eap-binding-04 (work in
              progress), October 2003.

JARI: (Editorial) I wonder if the above three are really informative.

OHBA: I agree.  The three references should be informative.  I'll move
them to informative references section.

Best regards,

Yoshihiro Ohba (Editor)

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 04 Feb 2004 18:07:56 -0800

-------

OHBA: OK.

-----

OHBA: OK.

----

OHBA: OK.

-----

-------

"
   PANA Client (PaC)

   Device Identifier (DI)

                                                                                
                                                                                
   Enforcement Point (EP)

   Master Session Key (MSK)

------- 
3. Protocol Overview

"
3. Protocol Overview

                                                                                
           PaC                   EP            PAA           AAA
           ---                   ---           ---           ---
                                                                                
                         PAA Discovery
                                                                                
                                     Authorization
                                  <-------------  (3)
                                                                                
                        Figure 1: PANA Framework

(End of Section 3)

------

OHBA: OK.

OHBA: OK.

-----

OHBA: OK.
------

OHBA: OK.

---------

                                                                                

4.13 PAA Implications

                                                                                

OHBA: OK.

-------

   "IKE involves

--
   g) Liveness test

OHBA: OK.

----

                                                                                

Best regards,

Yoshihiro Ohba (Editor)

---

From: Jari Arkko <[email-masked]>
Date: Thu, 05 Feb 2004 10:35:38 +0200

Yoshihiro Ohba wrote:
> I have one question to Jari on the definition of MSK (please
> see my comments below).

> MSK correct?  I am a bit confused about the distinction between MSK

The definition is right. But there is a question of whether you
should actually use AAA-Key and not MSK.

The difference between the MSK and the AAA-Key is that the MSK
is held by the EAP server i.e. an AAA node, whereas the AAA-Key
is the value that is communicated to the actual authenticator
i.e. PAA. So from this it is pretty clear that your draft should
really talk about the AAA-Key. On the other hand, while different
designs have been discussed in the EAP WG, in 802.11i the AAA-Key
is octets 0-31 of the MSK.

> OHBA: I agree.  How about re-arranging the contents of section 3 like:

Looks good, thanks.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 05 Feb 2004 10:35:38 +0200

Looks good, thanks.

--Jari