Re: [Pana] review of the pana protocol

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)

_______________________________________________
Pana mailing list
Pana@ietf.org
https://www1.ietf.org/mailman/listinfo/pana