Subject: [HOKEY] Review of draft-ietf-hokey-preauth-ps-01

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 08 Feb 2008 19:02:36 +0100

Hi all,

I have reviewed the document draft-ietf-hokey-preauth-ps-01.

The document is very well written and understandable, though i have a 
few comments and questions below (labelled with Rafa:  ).

<snip>

section 2 page 2:

   Handover often requires authorization for acquisition or modification

Rafa: authorization -> authentication and authorization

   of resources assigned to a mobile and the authorization needs
   interaction with a central authority in a domain.  In many cases an
   authorization procedure during a handover procedure follows an
   authentication procedure that also requires interaction with a
   central authority in a domain.  The delay introduced due to such an
   authentication and authorization procedure adds to the handover
   latency and consequently affects the ongoing multimedia sessions.
   The authentication and authorization procedure may include EAP
   authentication [RFC3748] where an AAA server may be involved in EAP
   messaging during the handover.  Depending upon the type of
   architecture, in some cases the AAA signals traverse all the way to
   the AAA server in the home domain of the mobile as well before the
   network service is granted to the mobile in the new network.

   Real-time communication and interactive traffic such as VoIP is very
   sensitive to the delay.  Thus it is desirable that interactions
   between the mobile and AAA servers must be avoided or be reduced

Ohba (Editor)            Expires April 20, 2008                 [Page 3]

<snip>

3.  Problem Statement

   Basic mechanism of handover is a three-step procedure involving i)
   discovery of potential points of attachment and their authenticators,
   ii) network selection procedure to determine the appropriate
   candidate network point of attachment and iii) handover or setting up
   of L2 and L3 connectivity to the target network point of attachment.
   Currently, security mechanisms for authentication and authorization
   is performed as part of the third step directly with the target

Rafa: is performed -> are performed

   network.  For example, in basic IEEE 802.11b based wireless networks,

Rafa: IEEE 802.11b -> IEEE 802.11

   the security mechanism involves performing a new IEEE 802.1X message
   exchange with the authenticator in the target AP (Access Point) to
   initiate an EAP exchange to the authentication server [WPA].
   Following a successful authentication, a four-way handshake with the

Rafa: I would suggest the sentence: "Following a successful 
authentication, a security association protocol named four-way handshake

is performed with the wireless station derives a new set of the session 
keys for use in data communications. 

Unless PMK (Pairwise Master Key) is not cached
   in the target AP, this mechanism is same as the initial setup to the
   AP with no particular optimizations for the handover scenario. 

Rafa: This sentence (above) is confusing to me. What do you mean with that?

The
   handover latency introduced by this security mechanism has proven to
   be larger than what is acceptable for some handover scenarios.

Rafa: add reference to the above sentence, "has proven []"

   Hence, improvement in the handover latency performance due to
   security procedures is a necessary objective for such scenarios.

   For example, if a mobile only needs 250 ms for "fast reconnect" then
   if it is moving at 60 mph (87 feet/second), then the mobile will have
   moved roughly 22 feet during the EAP authentication process.  This is
   larger than the average coverage overlap of a wireless LAN (WLAN).

   There is relevant work undertaken by various standards organizations.
   But these efforts are scoped to a specific access technology.  IEEE
   802.11f has defined context transfer between APs.  IEEE 802.11i
   defines a pre-authentication mechanism for use in 802.11 variant

Ohba (Editor)            Expires April 20, 2008                 [Page 4]

Internet-Draft  EAP Pre-authentication Problem Statement    October 2007

   wireless networks.  This mechanism allows mobile devices to pre-
   authenticate using EAP to one or more candidate authenticators over
   the wired medium, by way of the serving authenticator.  Presently,
   IEEE 802.11r WG has been working to define Fast BSS transition

Rafa: Add reference 802.11r

<snip>

   avoidable to generate a key for the candidate authenticator.  One
   case is an inter-domain handover without any trust relationship
   between domains.  Another case is an intra-domain handover where the
   access networks and/or the AAA infrastructure in the visited domain
   do not support handover keying and re-authentication.

Rafa: re-authentication -> fast re-authentication

Ohba (Editor)            Expires April 20, 2008                 [Page 5]

Internet-Draft  EAP Pre-authentication Problem Statement    October 2007

<snip>

   Note that EAP pre-authentication problem for intra-technology intra-
   subnet handover could be solved by each link-layer and is thus out of
   the scope of this document while a general solution developed at IETF
   can be used for intra-technology and intra-subnet scenarios as well.

   In EAP pre-authentication, AAA authentication and authorization for a
   candidate authenticator is performed while application sessions

Rafa: maybe it is better to change "application sessions" for other 
term: e.g. "on-going data communications"

 are
   in progress via the serving network.  The goal of EAP pre-
   authentication is to avoid AAA signaling for EAP when or soon after
   the device moves.  There are several AAA issues related to EAP pre-
   authentication.  The pre-authentication AAA issues are described in
   Section 6.

<snip>

Ohba (Editor)            Expires April 20, 2008                 [Page 7]

Internet-Draft  EAP Pre-authentication Problem Statement    October 2007

    Mobile             Serving              Candidate             AAA
     Node           Authenticator         Authenticator          Server
     (MN)                (SA)                 (CA)
      |                   |                    |                   |
      |                   |                    |                   |
      |       MN-CA Signaling (L2 or L3)       |       AAA         |
      |<------------------+------------------->|<----------------->|
      |                   |                    |                   |
      |                   |                    |                   |

                    Figure 2: Direct Pre-authentication

   In this type of pre-authentication, the serving authenticator
   forwards the EAP pre-authentication traffic as it would any other
   data traffic or there may be no serving authenticator at all in the
   serving access network.

   [I-D.ietf-pana-preauth] is identified as a protocol to realize direct
   pre-authentication.

Rafa: PANA is a protocol working on top of IP, but Fig. 2 specifies also 
L2. I would remove L2 from the fig.2

<snip>

5.2.  Context Binding

   When a candidate authenticator uses different EAP transport protocols
   for normal authentication and pre-authentication, a mechanisms is
   needed to bind link-layer independent context carried over pre-
   authentication signaling to the link-layer specific context of the
   link to be established between the mobile node and the candidate
   authenticator.  The link-layer independent context includes the
   identities of the peer and authenticator as well as the MSK.  The
   link-layer specific context includes link-layer addresses of the
   mobile node and the candidate authenticator.

   There are two possible approaches to address the context binding
   issue.  The first approach is based on communicating the lower-layer
   context as opaque data via pre-authentication signaling and perform
   the link-layer specific secure association procedure after handover.
   The second approach is based on running EAP over the link-layer of
   the candidate authenticator after handover using short-term
   credentials generated via pre-authentication, followed by the link-
   layer specific secure association procedure.  In this case, the
   short-term credentials are shared between the mobile node and the
   candidate authenticator, and hence the EAP server for the post-
   handover EAP resides in the candidate authenticator.

Rafa: clarify the term "post-handover EAP". Btw, does this paragraph 
assume that there will be a EAP signalling between peer and candidate 
authenticator after handover??

<snip>

6.  AAA Issues

   Most of the AAA documentations today do not distinguish between a
   full authentication and a pre-authentication and this creates a set
   of open issues:

   Pre-authentication authorization:   Many users may not be allowed to
      have more than one logon session at the time.  This means, when
      such users actively engage in an active session (as a result of a
      previously valid authentication), they will not be able to perform
      pre-authentication.  The AAA server currently has no way of
      distinguishing between a full authentication request and a pre-
      authentication request.

Ohba (Editor)            Expires April 20, 2008                [Page 10]

Internet-Draft  EAP Pre-authentication Problem Statement    October 2007

   Pre-authentication life time:   Currently AAA protocols define
      attributes (AVPs) carrying life time information for a full
      authentication session.  Even when a user profile and the AAA
      server support pre-authentication function, after the pre-
      authentication of a peer is complete, since the pre-authentication
      may be accompanied with a pre-authorization, the pre-
      authentication is typically valid only for a short amount of time.
      It is currently not possible for a AAA server to indicate to the
      AAA client or a peer what the life time of the pre- authenticated
      session is.  In other words, it is not clear to the peer or the
      NAS, when the pre-authentication will expire.

Rafa: is the above really an issue? I mean if NAS and AAA can 
distinguish whether it is a pre-authentication through some mechanism, 
couldn't the same attributes used for informing about session lifetime 
in regular authentication be used for pre-authentication?.

<snip>

7.  Security Considerations

 <snip>

   Second, consideration for the Channel Binding problem described in
   [I-D.ietf-eap-keying] is needed as lack of Channel Binding may enable
   an authenticator to impersonate another authenticator or communicate
   incorrect information via out-of-band mechanisms (such as via a AAA
   or lower layer protocol) [RFC3748].  It should be noted that it would
   be easier to launch such an impersonation attack for pre-
   authentication than normal authentication because an attacker does
   not need to be physically on the same link as the legitimate peer to

Rafa: is this paragraph assuming that "normal authentication" always 
happens in the same physical link?
doesn't it consider network access control at network-layer?

Ohba (Editor)            Expires April 20, 2008                [Page 12]

Internet-Draft  EAP Pre-authentication Problem Statement    October 2007

   send a pre-authentication trigger to the peer.  A simple solution
   would be to let the peer always initiate EAP pre-authentication and
   not allow EAP pre-authentication initiation from authenticator side.

Rafa: Just for clarification, if I understand correctly, the problem is 
that an attacker acting as authenticator
could start the pre-authentication process from any point in the 
network, correct?

If yes, i think it is not only something related with channel binding 
but also with the fact that an attacker can provoke, for example battery 
exhaustion, starting different EAP pre-auth with the mobile.

BR.

-- 
------------------------------------------------------
Rafael Marin Lopez
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: [email-masked]
------------------------------------------------------

_______________________________________________
HOKEY mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/hokey

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 10 Feb 2008 14:16:50 -0500

Hi Rafa,

Thank you very much for your review.  

Please see my comments inline.

> Rafa: authorization -> authentication and authorization

OK.

> Rafa: is performed -> are performed

OK.

> Rafa: IEEE 802.11b -> IEEE 802.11

OK.

> authentication, a security association protocol named four-way handshake

OK.

> Rafa: This sentence (above) is confusing to me. What do you mean with that?

This points to a case in which PMK is cached in the target AP when the
MN visited the AP, then EAP does not have to be performed when MN
re-visits the AP before the PMK cache expires.

> Rafa: add reference to the above sentence, "has proven []"

OK.  We will add a reference.

> Rafa: Add reference 802.11r

Sure.

> Rafa: re-authentication -> fast re-authentication

OK.

> term: e.g. "on-going data communications"

OK.

>       |       MN-CA Signaling (L2 or L3)       |       AAA         |

Yes, removing L2 from Figure 2 makes sense because section 1
explicitly mentions that EAP pre-authentication for intra-technology
intra-subnet handover is out of the scope of this document.  BTW, PANA
pre-authentication is not supposed to be used for inter-technology
pre-authentication where context binding is needed.

> authenticator after handover??

"the post handover EAP" is explained in the previous sentence as "EAP
over the link-layer of the candidate authenticator after handover".

> in regular authentication be used for pre-authentication?.

Do you have a specific mechanism in your mind?

> doesn't it consider network access control at network-layer?

I see your point.  Let us revise the text to:

"
  It should be noted that, when normal authentication uses link-layer
  EAP transport, it would be easier to launch such an impersonation
  attack for pre- authentication than normal authentication because an
  attacker does not need to be physically on the same link as the
  legitimate peer to send a pre-authentication trigger to the peer.
"

> exhaustion, starting different EAP pre-auth with the mobile.

Yes.  I found that it is related to the first threat.  It would be
better to move the sentence from the second threat to the the first
threat as follows:

"
   First, a possible resource consumption denial of service attack where
   an attacker that is not on the same IP link as the mobile node or the
   candidate authenticator may send unprotected pre-authentication
   messages to the mobile node or the candidate authenticator to let the
   legitimate mobile node and candidate authenticator spend their
   computational and bandwidth resources.  This attack is possible for
   both direct and indirect pre-authentication scenarios.  To mitigate
   this attack, the candidate network or authenticator should apply non-
   cryptograhpic packet filtering so that pre-authentication messages
   received from only a specific set of serving networks or
   authenticators are processed.  In addition, a simple solution for
   the peer side would be to let the peer always initiate EAP
   pre-authentication and not allow EAP pre-authentication initiation
   from authenticator side.
"

Best Regards,
Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 22 Feb 2008 12:44:26 +0100

Hi Yoshi,

sorry for my delayed answer. Thanks for addressing my comments. I am ok
with them.
> Do you have a specific mechanism in your mind?
My question is why "it is currently not possible for a AAA server to
indicate to the AAA client or a peer what the life time of the
pre-authenticated session is"?

My point is that, assming the AAA protocal has pre-authentication
support (e.g. it has a flag P saying it is pre-authentication)
i am not sure why it is required to define a special attribute for
pre-authentication lifetime. For example in Diameter, why could not the
Authorization-Lifetime AVP be used in this case.?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 22 Feb 2008 07:28:20 -0500

Hi Rafa,

As far as I know, there is no standard attribute, AVP or flag in AAA
protocols to indicate pre-authentication.  In some 802.11 deployment
the absense of SSID in Called-Station-ID can indicate
pre-authentication, but it's not a standard or generally applicable to
any link layer.  So in general Authorization-Lifetime AVP can only
mean the lifetime of authorization after normal authentication.

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Fri, 22 Feb 2008 16:24:54 +0100

Hi Yoshi,

> protocols to indicate pre-authentication. 
Yes , i know that.

I guess it is assumed that, in the pre-authentication step, both pre-authentication authorization information, and authorization is case of handover to the
authenticator, is provided at the same time. 

Then you would need both:

Pre-auth Authz Lifetime AVP (pre-auth)
auth lifetime AVP (in case of handover to the authenticator)

I agree then.

>  In some 802.11 deployment

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 22 Feb 2008 10:34:02 -0500

Yes, that is the case.

Yoshihiro Ohba