[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[HOKEY] preauth problem statement
The second WGLC completed with no comments on the preauth problem
statement. Consequently I'd like to move the document forward. I did
another read-through of the document and found a number of editorial
issues (see below). Yoshi -- please correct them and submit a revised
document. Meanwhile I'll work on a proto writeup and get the document
moved forward for IESG review.
--
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
Abstract
EAP pre-authentication is defined as the use of EAP to pre-establish
EAP keying material on a target authenticator prior to arrival of the
peer at the access network managed by that authenticator. This draft
discusses EAP pre-authentication problems in details.
TCC> Spell out EAP the first time it's used.
1. Introduction
... Similarly, a streaming application has the
tolerable packet (SDU) error rates ranging from 0.1 to 0.00001 and
the transfer delay of less than 300 ms. Thus, any optimized handoff
mechanism will need to take care of these factors into consideration
in order to be able to support a heterogeneous handover that is
agnostic to link-layer technologies.
TCC> s/the tolerable packet/a tolerable packet/
TCC> s/to take care of these factors/to take these factors/
This draft discusses EAP pre-authentication problems in details wherFrom hokey-bounces at ietf.org Thu Jul 17 11:57:29 2008
Return-Path: <hokey-bounces at ietf.org>
X-Original-To: hokey-archive at optimus.ietf.org
Delivered-To: ietfarch-hokey-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 22D9E3A6A1C;
Thu, 17 Jul 2008 11:57:29 -0700 (PDT)
X-Original-To: hokey at core3.amsl.com
Delivered-To: hokey at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9B4B03A6A7C
for <hokey at core3.amsl.com>; Thu, 17 Jul 2008 07:47:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id vfi20xRxCORO for <hokey at core3.amsl.com>;
Thu, 17 Jul 2008 07:47:35 -0700 (PDT)
Received: from bacon.cs.umd.edu (server-nat-4.cs.umd.edu [128.8.127.147])
by core3.amsl.com (Postfix) with ESMTP id 99AAB3A69BD
for <hokey at ietf.org>; Thu, 17 Jul 2008 07:47:35 -0700 (PDT)
Received: from [127.0.0.1] ([12.107.91.2]) (authenticated bits=0)
by bacon.cs.umd.edu (8.13.1/8.14.1) with ESMTP id m6HEm0mm007091
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
for <hokey at ietf.org>; Thu, 17 Jul 2008 10:48:01 -0400
Message-ID: <487F85CB.70203 at umd.edu>
Date: Thu, 17 Jul 2008 10:47:55 -0700
From: Charles Clancy <tcc at umd.edu>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: hokey at ietf.org
X-CSD-MailScanner-Information: Please email staff at cs.umd.edu for more
information
X-CSD-MailScanner: Found to be clean
X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.8,
required 5, autolearn=not spam, ALL_TRUSTED -1.80)
X-CSD-MailScanner-From: tcc at umd.edu
X-Mailman-Approved-At: Thu, 17 Jul 2008 11:57:27 -0700
Subject: [HOKEY] preauth problem statement
X-BeenThere: hokey at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: HOKEY WG Mailing List <hokey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hokey>,
<mailto:hokey-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/hokey>
List-Post: <mailto:hokey at ietf.org>
List-Help: <mailto:hokey-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hokey>,
<mailto:hokey-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: hokey-bounces at ietf.org
Errors-To: hokey-bounces at ietf.org
The second WGLC completed with no comments on the preauth problem
statement. Consequently I'd like to move the document forward. I did
another read-through of the document and found a number of editorial
issues (see below). Yoshi -- please correct them and submit a revised
document. Meanwhile I'll work on a proto writeup and get the document
moved forward for IESG review.
--
t. charles clancy, ph.d. eng.umd.edu/~tcc
electrical & computer engineering, university of maryland
Abstract
EAP pre-authentication is defined as the use of EAP to pre-establish
EAP keying material on a target authenticator prior to arrival of the
peer at the access network managed by that authenticator. This draft
discusses EAP pre-authentication problems in details.
TCC> Spell out EAP the first time it's used.
1. Introduction
... Similarly, a streaming application has the
tolerable packet (SDU) error rates ranging from 0.1 to 0.00001 and
the transfer delay of less than 300 ms. Thus, any optimized handoff
mechanism will need to take care of these factors into consideration
in order to be able to support a heterogeneous handover that is
agnostic to link-layer technologies.
TCC> s/the tolerable packet/a tolerable packet/
TCC> s/to take care of these factors/to take these factors/
This draft discusses EAP pre-authentication problems in details where
EAP pre-authentication is defined as the utilization of EAP to pre-
establish EAP keying material on an EAP authenticator prior to
arrival of the mobile device that acts as an EAP peer, at the access
network served by that authenticator.
TCC> s/in details/in detail,/
2. Terminology
TCC> For EAP-based terminology, I think you should just site 3748,
rather than provide your own definitions.
3. Problem Statement
Basic mechanism of handover is a three-step procedure involving i)
TCC> s/Basic/The basic/
discovery of candidate network points of attachment and their
authenticators, ii) network selection procedure to determine the
...
the peer and the target authenticator to derive a new set of link-
layer ciphering keys from EAP keying material such as MSK. The third
TCC> s/such as MSK/such as the MSK/
step may require full EAP authentication in the absence of any
particular optimization for handover key management. The handover
latency introduced by full EAP authentication has proven to be larger
than that is acceptable for real-time applications scenarios as
described in [MQ7]. Hence, improvement in the handover latency
performance due to EAP is a necessary objective for such scenarios.
There is relevant work undertaken by various standards organizations,
but these efforts are scoped to a specific link layer technology.
...
authenticator. IEEE 802.11r [802.11r] defines Fast BSS transition
mechanisms involving a definition of key management hierarchy and
TCC> s/definition of key/definition of a key/
setup of session keys before the re-association to the target AP in
the same 802.11r mobility domain. These mechanisms, as indicated
before, are defined for IEEE 802.11 technologies and are only
applicable for intra-access-domain handovers and fall short when it
comes to inter-technology handovers. They also require L2 (e.g.,
Ethernet) connectivity for transfer of key management signaling to a
candidate or the target AP. Especially, a solution is needed to
TCC> s/to a candidate or the target/to the target/
TCC> s/Especially, a/A/
enable EAP pre-authentication for inter-access-domain or inter-ESS
handovers in IEEE 802.11.
As various flavors of wireless technologies are increasingly
available, there is a growing demand for seamless inter-technology
mobility and handovers. This is particularly beneficial in the
TCC> s/and handovers//
presence of high bandwidth, wireless technologies (e.g., IEEE 802.11)
with only hotspot-like coverages while the overlay licensed wireless/
TCC> s/coverages/coverage/
cellular coverages are expensive and relatively low bandwidth.
TCC> s/coverages/coverage/
Hence, the security optimization mechanisms for better handover
performance must be looked at from the IP level so as to make it a
common method over different access technologies.
Optimized solutions for secure inter-authenticator handovers can be
largely seen as security context transfer, ERP [I-D.ietf-hokey-erx],
TCC> s/transfer, ERP/transfer: ERP/
or EAP pre-authentication. Security context transfer involves
transfer of reusable key context to the new point of attachment.
However, the recent AAA key management requirement [RFC4962] does not
TCC> s/requirement [RFC4962] does/requirements [RFC4962] do/
EAP pre-authentication has general applicability to various
deployment scenarios of the above handover cases in which proactive
TCC> s/of the above handover cases//
signaling can take effect. In other words, applicability of EAP pre-
authentication is limited to the scenarios where candidate
authenticators can be discovered, an accurate prediction of movement
can be easily made. Also the effectiveness of EAP pre-authentication
TCC> s/discovered, an/discovered and an/
may be less significant for particular inter-technology handover
scenarios where simultaneous use of multiple technologies is not a
major concern.
Figure 1 shows the functional elements that are related to EAP pre-
authentication.
+------+ +-------------+ +------+
| Peer |---------| Serving | / \
| | |Authenticator|---/ \
+------+ +-------------+ / \
. / \ +--------------+
. Move + IP Network +---|AAA/EAP Server|
. \ / +--------------+
v +-------------+ \ /
| Candidate |---\ /
|Authenticator| \ /
+-------------+ +------+
Figure 1: EAP Pre-authentication Functional Elements
TCC> This implies a single AAA server for both authenticators. What
about multiple AAA servers with different user credentials?
4. Usage Scenarios
There are two scenarios for how EAP pre-authentication signaling can
happen among a peer, serving authenticator, candidate authenticator
and AAA server, depending on how the serving authenticator is
involved in the EAP pre-authentication signaling. It is assumed in
both scenarios that there is no direct L2 connectivity between a peer
and a CA. No security association between the serving authenticator
TCC> CA used for the first time here. Try and use acronyms consistently.
and the candidate authenticator is required for either pre-
authentication scenario (see Section 7 for more detailed discussion).
5.2. Context Binding
There are at least two possible approaches to address the context
binding issue. The first approach is based on communicating the link
layer context as opaque data via pre-authentication signaling. The
second approach is based on running EAP over the link layer of the
candidate authenticator after the peer arrives at the authenticator
using short-term credentials generated via pre-authentication. In
this case, the short-term credentials are shared between the peer and
the candidate authenticator, and hence the EAP server for the EAP
performed after the peer arrives at the target authenticator resides
TCC> "EAP performed" is unclear. Perhaps "EAP method execution
performed" or something similar would work better.
in the authenticator. In both approaches, context binding needs to
be securely made between the peer and the candidate authenticator.
Also, the peer is not fully authorized by the candidate authenticator
until the peer completes the link layer specific secure association
procedure with the authenticator using the link layer signaling.
6. AAA Issues
Pre-authentication lifetime: Currently AAA protocols define
attributes carrying lifetime information for a normal
authentication session. Even when a user profile and the AAA
server support pre-authentication, the lifetime for a pre-
TCC> s/support/supports/
authentication session is typically valid only for a short amount
of time because the peer has not completed its authentication at
the target link layer. It is currently not possible for a AAA
server to indicate to the AAA client or a peer the lifetime of the
pre-authenticated session unless AAA protocols are extended to
carry pre-authentication session lifetime information. In other
words, it is not clear to the peer or the authenticator when the
pre-authentication session will expire.
Completion of network attachment: Once the peer has successfully
attached to the new point of attachment, it needs to convert its
authentication state from pre-authenticated to fully attached and
authorized. There may need to be a mechanism within the AAA
protocol to provide this indication to the AAA server if the AAA
server needs to differentiate between pre-authentication and
normal authentication.
TCC> Presumably for billing this would be extremely important. You
probably don't want to charge a preauth'd person until they are fully
attached.
Session Resumption: In case the peer cycles between a network N1
with which it has a normal authentication state to another network
N2 and then back to N1, it should be possible to simply convert
the full authentication state to a pre-authenticated state. The
problems around handling session lifetime and keying material
caching needs to be dealt with.
TCC> s/needs/need/
7. Security Considerations
Since pre-authentication described in this document needs to work
across multiple authenticators, any solution needs to consider the
following security threats.
First, a resource consumption denial of service attack is possible,
where an attacker that is not on the same IP link as the legitimate
peer or the candidate authenticator may send unprotected pre-
authentication messages to the legitimate peer or the candidate
authenticator. As a result, they may spend their computational and
bandwidth resources for processing pre-authentication messages sent
TCC> s/resources for/resources on/
by the attacker. This attack is possible for both direct and
indirect pre-authentication scenarios. To mitigate this attack, the
candidate network or authenticator may apply non-cryptographic 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.
TCC> s/from authenticator side/from an authenticator/
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 is
relatively 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.
TCC> This section specifically covers threats introduced to the EAP
model by preauthentication. This should be stated clearly, and
references should be made to other documents that describe general EAP
and handover security issues.
_______________________________________________
HOKEY mailing list
HOKEY at ietf.org
https://www.ietf.org/mailman/listinfo/hokey
e
EAP pre-authentication is defined as the utilization of EAP to pre-
establish EAP keying material on an EAP authenticator prior to
arrival of the mobile device that acts as an EAP peer, at the access
network served by that authenticator.
TCC> s/in details/in detail,/
2. Terminology
TCC> For EAP-based terminology, I think you should just site 3748,
rather than provide your own definitions.
3. Problem Statement
Basic mechanism of handover is a three-step procedure involving i)
TCC> s/Basic/The basic/
discovery of candidate network points of attachment and their
authenticators, ii) network selection procedure to determine the
...
the peer and the target authenticator to derive a new set of link-
layer ciphering keys from EAP keying material such as MSK. The third
TCC> s/such as MSK/such as the MSK/
step may require full EAP authentication in the absence of any
particular optimization for handover key management. The handover
latency introduced by full EAP authentication has proven to be larger
than that is acceptable for real-time applications scenarios as
described in [MQ7]. Hence, improvement in the handover latency
performance due to EAP is a necessary objective for such scenarios.
There is relevant work undertaken by various standards organizations,
but these efforts are scoped to a specific link layer technology.
...
authenticator. IEEE 802.11r [802.11r] defines Fast BSS transition
mechanisms involving a definition of key management hierarchy and
TCC> s/definition of key/definition of a key/
setup of session keys before the re-association to the target AP in
the same 802.11r mobility domain. These mechanisms, as indicated
before, are defined for IEEE 802.11 technologies and are only
applicable for intra-access-domain handovers and fall short when it
comes to inter-technology handovers. They also require L2 (e.g.,
Ethernet) connectivity for transfer of key management signaling to a
candidate or the target AP. Especially, a solution is needed to
TCC> s/to a candidate or the target/to the target/
TCC> s/Especially, a/A/
enable EAP pre-authentication for inter-access-domain or inter-ESS
handovers in IEEE 802.11.
As various flavors of wireless technologies are increasingly
available, there is a growing demand for seamless inter-technology
mobility and handovers. This is particularly beneficial in the
TCC> s/and handovers//
presence of high bandwidth, wireless technologies (e.g., IEEE 802.11)
with only hotspot-like coverages while the overlay licensed wireless/
TCC> s/coverages/coverage/
cellular coverages are expensive and relatively low bandwidth.
TCC> s/coverages/coverage/
Hence, the security optimization mechanisms for better handover
performance must be looked at from the IP level so as to make it a
common method over different access technologies.
Optimized solutions for secure inter-authenticator handovers can be
largely seen as security context transfer, ERP [I-D.ietf-hokey-erx],
TCC> s/transfer, ERP/transfer: ERP/
or EAP pre-authentication. Security context transfer involves
transfer of reusable key context to the new point of attachment.
However, the recent AAA key management requirement [RFC4962] does not
TCC> s/requirement [RFC4962] does/requirements [RFC4962] do/
EAP pre-authentication has general applicability to various
deployment scenarios of the above handover cases in which proactive
TCC> s/of the above handover cases//
signaling can take effect. In other words, applicability of EAP pre-
authentication is limited to the scenarios where candidate
authenticators can be discovered, an accurate prediction of movement
can be easily made. Also the effectiveness of EAP pre-authentication
TCC> s/discovered, an/discovered and an/
may be less significant for particular inter-technology handover
scenarios where simultaneous use of multiple technologies is not a
major concern.
Figure 1 shows the functional elements that are related to EAP pre-
authentication.
+------+ +-------------+ +------+
| Peer |---------| Serving | / \
| | |Authenticator|---/ \
+------+ +-------------+ / \
. / \ +--------------+
. Move + IP Network +---|AAA/EAP Server|
. \ / +--------------+
v +-------------+ \ /
| Candidate |---\ /
|Authenticator| \ /
+-------------+ +------+
Figure 1: EAP Pre-authentication Functional Elements
TCC> This implies a single AAA server for both authenticators. What
about multiple AAA servers with different user credentials?
4. Usage Scenarios
There are two scenarios for how EAP pre-authentication signaling can
happen among a peer, serving authenticator, candidate authenticator
and AAA server, depending on how the serving authenticator is
involved in the EAP pre-authentication signaling. It is assumed in
both scenarios that there is no direct L2 connectivity between a peer
and a CA. No security association between the serving authenticator
TCC> CA used for the first time here. Try and use acronyms consistently.
and the candidate authenticator is required for either pre-
authentication scenario (see Section 7 for more detailed discussion).
5.2. Context Binding
There are at least two possible approaches to address the context
binding issue. The first approach is based on communicating the link
layer context as opaque data via pre-authentication signaling. The
second approach is based on running EAP over the link layer of the
candidate authenticator after the peer arrives at the authenticator
using short-term credentials generated via pre-authentication. In
this case, the short-term credentials are shared between the peer and
the candidate authenticator, and hence the EAP server for the EAP
performed after the peer arrives at the target authenticator resides
TCC> "EAP performed" is unclear. Perhaps "EAP method execution
performed" or something similar would work better.
in the authenticator. In both approaches, context binding needs to
be securely made between the peer and the candidate authenticator.
Also, the peer is not fully authorized by the candidate authenticator
until the peer completes the link layer specific secure association
procedure with the authenticator using the link layer signaling.
6. AAA Issues
Pre-authentication lifetime: Currently AAA protocols define
attributes carrying lifetime information for a normal
authentication session. Even when a user profile and the AAA
server support pre-authentication, the lifetime for a pre-
TCC> s/support/supports/
authentication session is typically valid only for a short amount
of time because the peer has not completed its authentication at
the target link layer. It is currently not possible for a AAA
server to indicate to the AAA client or a peer the lifetime of the
pre-authenticated session unless AAA protocols are extended to
carry pre-authentication session lifetime information. In other
words, it is not clear to the peer or the authenticator when the
pre-authentication session will expire.
Completion of network attachment: Once the peer has successfully
attached to the new point of attachment, it needs to convert its
authentication state from pre-authenticated to fully attached and
authorized. There may need to be a mechanism within the AAA
protocol to provide this indication to the AAA server if the AAA
server needs to differentiate between pre-authentication and
normal authentication.
TCC> Presumably for billing this would be extremely important. You
probably don't want to charge a preauth'd person until they are fully
attached.
Session Resumption: In case the peer cycles between a network N1
with which it has a normal authentication state to another network
N2 and then back to N1, it should be possible to simply convert
the full authentication state to a pre-authenticated state. The
problems around handling session lifetime and keying material
caching needs to be dealt with.
TCC> s/needs/need/
7. Security Considerations
Since pre-authentication described in this document needs to work
across multiple authenticators, any solution needs to consider the
following security threats.
First, a resource consumption denial of service attack is possible,
where an attacker that is not on the same IP link as the legitimate
peer or the candidate authenticator may send unprotected pre-
authentication messages to the legitimate peer or the candidate
authenticator. As a result, they may spend their computational and
bandwidth resources for processing pre-authentication messages sent
TCC> s/resources for/resources on/
by the attacker. This attack is possible for both direct and
indirect pre-authentication scenarios. To mitigate this attack, the
candidate network or authenticator may apply non-cryptographic 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.
TCC> s/from authenticator side/from an authenticator/
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 is
relatively 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.
TCC> This section specifically covers threats introduced to the EAP
model by preauthentication. This should be stated clearly, and
references should be made to other documents that describe general EAP
and handover security issues.
_______________________________________________
HOKEY mailing list
HOKEY at ietf.org
https://www.ietf.org/mailman/listinfo/hokey