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: Tschofenig Hannes <[email-masked]>
Date: Thu, 5 Feb 2004 09:25:33 +0100

hi alper, 
hi jari, 

thanks for your comments jari. just a quick comment:

~snip~snip
> OK, we shall open an issue and track this.

alper, i have written a detailed text for this some time ago. we might want
to look at it again. i don't know why we "dropped" it. the text which is
used that time as input can be found in Section 16.1 of
http://www.tschofenig.com/drafts/draft-schulzrinne-nsis-casp-00.pdf
(Scout is a discovery mechanism.) 

maybe we can find the original text. 

ciao
hannes

---

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 5 Feb 2004 09:25:33 +0100

hi alper, 
hi jari, 

~snip~snip

ciao
hannes