[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HOKEY] WGLC: draft-ietf-hokey-preauth-ps-02
Subir,
Thank you very much for your detailed review. Please see my comments below.
On Tue, Apr 08, 2008 at 02:06:00AM -0400, Subir Das wrote:
> Put my comments on the document and is attached herewith. Search for
> 'SD'. The draft describes the problem nicely with issues but it requires
> a good amount
> of editing. Some parts of the draft may not be required for example,
> Appendix.
> Also a lot of abbreviations need to be expanded. May be a good idea
> to add a terminology section.
>
> regards,
> _Subir
>
>
> Abstract
>
> EAP pre-authentication is defined as the utilization of EAP to pre-
> establish EAP keying material on an authenticator prior to arrival of
> the peer at the access network managed by that authenticator.
>
> SD> Instead of ?on an authenticator? it may be appropriate to say ?on a target authenticator?. Also ?use? may be better than ?utilization?
Agreed.
> 2. Introduction
>
> When a mobile during an active communication session moves from one
> access network to another access network and changes its point of
> attachment it is subjected to disruption in the continuity of service
> because of the associated handover operation. During the handover
> process, when the mobile changes its point-of-attachment in the
> network, it may change its subnet or administrative domain it is
> connected to. We provide in Appendix A some performance requirement
> that are needed to support an interactive real-time communication
> such as VoIP and thus can serve as the guidelines for handover
> optimization.
>
> SD> General comment: Word ?mobile? is used in several places and ?mobile
> node? is used in other places. I think it should be ?mobile node? everywhere.
We will fix the terminology problem.
>
> SD> It is not clear from the above paragraph whether the mobile node is performing a handover using a single radio interface or always active dual radio interface. The performance requirement in Appendix A seems to be out of context here. The information in Appendix is valuable for a problem statement draft but needs to find the appropriate place to refer it.
Charles has a similar comment on Appendix A. We will work on
shortening Appendix A and move the content to the main body, perhaps
in this section.
>
>
> Handover often requires authentication and authorization for
> acquisition or modification 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
>
> SD> Why only ?multimedia? sessions?
How about s/multimedia/application/?
>
> sessions [MQ7]. The authentication and authorization procedure may
> include EAP authentication [RFC3748] where an AAA server may be
> involved in EAP messaging during the handover.
>
>
> SD> I assume the draft is about using EAP. So it should not use the term ?may? in the above sentence.
I agree not to use 'may' here.
> 3. Problem Statement
>
> Basic mechanism of handover is a three-step procedure involving i)
> discovery of potential points of attachment and their authenticators,
>
> SD> ?target? may be better than ?potential? above
or 'candidate'.
>
> 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
> are performed as part of the third step directly with the target
> network. For example, in basic IEEE 802.11 based wireless networks,
> 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 secure association protocol
> named four-way handshake 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. The handover latency
> introduced by this security mechanism has proven to be larger than
> what is acceptable for some handover scenarios [MQ7].
>
> SD> May be appropriate to say that ?The handover latency
> introduced by this security mechanism has proven to be larger than
> that is acceptable for real time applications as described in [MQ7].?
OK.
>
>
> 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).
>
> SD> The above paragraph seems to be not relevant here. The roaming problem within 802.11 networks is addressed by 802.11 task groups. Is the above example related to between wi-fi networks or between wi-fi and other networks?
This is for handovers between wi-fi networks. I think we can remove
this paragraph.
>
> 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
> wireless networks.
>
> SD> What does the ?variant? mean above?
Since 802.11i pre-authentication is already part of IEEE Std 802.11 - 2007,
we can revise the sentence to:
"IEEE 802.11 [802.11] defines a pre-authentication mechanism for use in
802.11 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. IEEE 802.11r
> [802.11r] defines Fast BSS transition mechanisms involving a
> definition of key management hierarchy and setup of session keys
> before the re-association to the target AP. These mechanisms, as
> indicated before, are defined for IEEE 802.11 technologies and are
> only applicable within a certain access domain and fall short when it
> comes to inter-access technology handovers. They also require L2
> (e.g., Ethernet) connectivity for transfer of encapsulated signaling
>
> SD> What ? encapsulating signaling??
We can revise the sentence to:
"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
> enable EAP pre-authentication in IEEE 802.11 to work even if the
> station and AP are not members of the same VLAN.
>
> As various flavors of wireless technologies are increasingly
> available, there is a growing demand for seamless inter-access
> technology mobility and handovers. This is particularly beneficial
> in the presence of high bandwidth wireless technologies (e.g., IEEE
> 802.11a/b/g) with only hotspot like coverages while the overlay
> licensed wireless/cellular coverages are expensive and relatively
> lower bandwidth. There is a strong motivation to allow seamless
> inter-technology handovers for all kinds of data communications.
> 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.
>
> SD> Some parts of the above paragraph are already mentioned earlier and can be removed.
OK, we will work on that.
>
> Solutions for inter-authenticator mobility security optimizations can
> be largely seen as security context transfer, handover keying or EAP
> pre-authentication. Security context transfer involves transfer of
> reusable key context in the new point of attachment. However, the
> recent AAA key management requirement [RFC4962] does not recommend
> horizontal context transfer of reusable key context because of domino
> effect in which a compromise of an authenticator will lead to a
> compromise of another authenticator.
>
> SD> Reference on domino effect may be good.
It is in [RFC4962].
>
> Handover keying and re-
> authentication [I-D.ietf-hokey-reauth-ps] uses an existing EAP-
> generated key for deriving a re-authentication key to be distributed
> to a HOKEY server in a visited domain in order to reduce the handover
> delay, which eliminates the need for running a full EAP
> authentication with the EAP server in the home domain for handovers
> within the visited domain. On the other hand, there are certain
> cases where an EAP-generated key does not exist or is not usable for
> handover keying at the time of handover and an EAP run is not
> 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 low-latency re-authentication.
> EAP pre-authentication discussed in this document is mainly to deal
> with an environment where the mobile device and candidate
> authenticators are not in the same subnet or of the same link-layer
> technology.
>
>
> SD> The above assumption needs to be consistent across the draft. Some earlier texts need to be reworded accordingly.
OK.
>
> Such use of EAP pre-authentication would enable the
> mobile device to authenticate and setup keys prior to connecting to
> one of the candidate authenticators.
>
> This framework has general applicability to various deployment
> scenarios in which proactive signaling can take effect. In other
> words, applicability of EAP pre-authentication is limited to the
> scenarios where candidate authenticators can be easily discovered, an
> accurate prediction of movement can be easily made.
>
> Also the
> effectiveness of EAP pre-authentication may be less significant for
> particular inter-technology handover scenarios where simultaneous use
> of multiple technologies is not a major concern or where there is
> sufficient radio-coverage overlap among different technologies.
>
> SD> The above paragraph is not very clear. Is it the case of using multiple radio interfaces? If the overlapping radio coverage is not there how the seamless handover would be possible? Does EAP pre-authentication assume that it is only applicable where overlapping coverage is not available?
I think we should remove "or where there is sufficient radio-coverage
overlap among different technologies" as some overlapping coverage
would be still needed for seamless handover.
>
> 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 ongoing 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.
>
> Figure 1 shows the functional elements that are related to EAP pre-
> authentication.
>
> +------+ +-------------+ +------+
> |Mobile|---------| Serving | / \
> | Node | |Authenticator|---/ \
> +------+ +-------------+ / \
> . / \ +----------+
> . Move + Internet +---|AAA Server|
> . \ / +----------+
> v +-------------+ \ /
> | Candidate |---\ /
> |Authenticator| \ /
> +-------------+ +------+
>
> Figure 1: EAP Pre-authentication Functional Elements
>
>
> SD> What is the ?Internet? bubble in Figure 1? It may not be a good example. Instead it may show the core network. Normally AAA servers are not just connected to the Internet like this?
Charles have the same comment. We will revise Figure 1.
>
> A mobile node is attached to the serving access network. Before the
> mobile node performs handover from the serving access network to a
> candidate access network, it performs EAP pre-authentication with a
> candidate authenticator, an authenticator in the candidate access
> network, via the serving access network. The mobile node may perform
> EAP pre-authentication with one or more candidate authenticators. It
> is assumed that each authenticator has an IP address when
> authenticators are on different IP links.
>
> SD> Does it mean that authenticators will not have an IP address when they are on the same IP link. Does it mean to say that authenticators have separate IP address when they are on different IP links?
It means that each authenticator has an IP address. We will revise
the sentence accordingly.
>
>
> It is assumed that there
> is at least one candidate authenticator in each candidate access
> network while the serving access network may or may not have a
> serving authenticator.
>
> SD> Is it true that serving network may not have a serving authenticator?
> If it is true, how come in the first case it enters into the network? Is serving network is an open network? If so, is it a valid handover scenario and is EAP pre-authentication applicable there? Also use case scenario does not cover it.
The serving network could be an open access L2 network and may be
using http authentication. Also there may be no roaming agreement
between the serving and target networks. EAP pre-authentication is
applicable to such scenarios.
>
> The serving and candidate access networks may
> use different link-layer technologies.
>
> Each authenticator has the functionality of EAP authenticator which
> is either standalone EAP authenticator or pass-through EAP
> authenticator. When an authenticator acts as a standalone EAP
> authenticator, it also has the functionality of EAP server. On the
> other hand, when an authenticator acts as a pass-through EAP
> authenticator, it communicates with EAP server typically implemented
> on a AAA server using a AAA protocol such as RADIUS and Diameter.
>
> SD> May be appropriate to say that ?using AAA transport protocol such as Radius and Diameter?
OK.
>
> If the candidate authenticator is of an existing link-layer
>
> SD> What is the meaning of ?existing? here? It is better to delete it.
OK.
>
> technology that uses an MSK (Master Session Key)
> [I-D.ietf-eap-keying] for generating lower-layer ciphering keys, EAP
> pre-authentication is used for proactively generating the MSK for the
> candidate authenticator.
>
>
> 4. Usage Scenarios
>
> There are two scenarios on how EAP pre-authentication signaling can
> happen among a mobile node, a serving authenticator, a candidate
> authenticator and a AAA server, depending on how the serving
> authenticator is involved in the EAP pre-authentication signaling.
> No security association between the serving authenticator and the
> candidate authenticator is required for both pre-authentication
> scenarios (see Section 7 for more detailed discussion).
>
> 4.1. Direct Pre-authentication
>
> Direct pre-authentication signaling is shown in Figure 2.
>
> Mobile Serving Candidate AAA
> Node Authenticator Authenticator Server
> (MN) (SA) (CA)
> | | | |
> | | | |
> | MN-CA Signaling (L3) | AAA |
> |<------------------+------------------->|<----------------->|
> | | | |
> | | | |
>
> Figure 2: Direct Pre-authentication
>
> SD> Does the MN-CA Signaling always needs to happen via L3? It may be worth mentioning the underlying assumption here.
The assumption is that there is no direct L2 connectivity between MN
and CA. We can add the assumption.
> 4.2. Indirect Pre-authentication
>
> Indirect pre-authentication signaling is shown in Figure 3.
>
> Mobile Serving Candidate AAA
> Node Authenticator Authenticator Server
> (MN) (SA) (CA)
> | | | |
> | | | |
> | MN-SA Signaling | SA-CA Signaling | AAA |
> | (L2 or L3) | (L3) | |
> |<----------------->|<------------------>|<----------------->|
> | | | |
> | | | |
>
> Figure 3: Indirect Pre-authentication
>
> With indirect pre-authentication, the serving authenticator is
> involved in EAP pre-authentication signaling. Indirect pre-
> authentication is needed if the MN cannot discover the CA's IP
> address or if IP communication is not allowed between the candidate
> authenticator and unauthorized nodes for security reasons.
>
> SD> IP communication may not even be possible even if mobile node is authorized, say, because of topology.
We can add the topology reason here.
>
> 5. Architectural Considerations
>
> There are two architectural issues relating to pre-authentication,
> i.e., authenticator discovery and context binding.
>
> SD> Is context binding an architectural issue or a general issue? Location of target authenticator may have some architectural implications. How about transport?
The context binding issue is specific to L3 pre-authentication, and
not a general issue. Transport (direct or indirect) does not have
architectural implications in terms of context binding.
>
> 5.1. Authenticator Discovery
>
> In general, pre-authentication requires an address of a candidate
> authenticator to be discovered either by a mobile node or by a
> serving authenticator prior to handover. An authenticator discovery
> protocol is typically defined as a separated protocol from a pre-
> authentication protocol.
>
> SD> Replace ?separated? by ?separate?
OK.
>
> When pre-authentication is used for inter-
> technology or inter-subnet handover, a candidate authenticator needs
> to have a global IP address and a mechanism for discovering the
> candidate authenticators IP address is needed.
>
> SD> Does it always require to have a global IP address even if serving and candidate authenticators are within one operator?s domain
A global address may not be needed for intra-domain handover. We can
revise the text to:
"
When pre-authentication is used for inter-technology or inter-subnet
handover, a candidate authenticator needs to have an IP address and a
mechanism for discovering the candidate authenticators IP address is
needed. For inter-domain handover, the IP address of a candidate
authenticator needs to be global unique.
"
>
> For example, IEEE
> 802.21 Information Service (IS) [802.21] provides a link-layer
> independent mechanism for obtaining neighboring network information
> by defining a set of Information Elements (IEs), where one of the IEs
> is defined to contain an IP address of a point of attachment. IEEE
> 802.21 IS queries for such an IE may be used as a method for
> authenticator discovery.
>
>
> An authenticator discovery mechanism requires a database on the
> neighboring network information. Provisioning of a server with such
> a database is another issue.
>
> SD> The above is a solution and does it require to have in the problem statement document?
The above paragraph was added based on Ajay Rajkumar's review. I
think this is a good to have, while I agree with you that it is not
mandatory to have in the problem statement document.
>
>
> 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.
>
> SD> Is it true that this context binding needs to happen after the handover?
> If so it may be appropriate to reflect that in the last sentence of the above paragraph.
Context binding can happen before handover.
>
> 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.
>
> SD> Last part of the above sentence is not clear.
The last part means that post-handover EAP terminates between MN and
CA, and does not require AAA signaling.
>
> In both
> approaches, the binding needs to be securely made between the peer
> and the candidate authenticator using a security association
> established via pre-authentication.
>
>
> 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.
>
>
> SD> The assumption here seems to me that mobile node has performed the network access authentication in the first place. Therefore, the earlier statement saying that serving network may or may not have an authenticator is not correct. Pl. refer to earlier comment on this as well.
I don't think this contradicts with the earlier statement. If there
is no authenticator in the serving network, then the mobile node will
be able to perform pre-authentication to the target network even if
the AAA server does not allow more than one logon session. In other
words, there is no logon session before pre-authentication in this
case.
>
> 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.
>
> SD> The above sentence may need to be rephrased.
OK.
>
> 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.
>
> SD> May be appropriate to add ?unless extended?
OK.
>
> In other words, it is not clear to the peer or the
> NAS, when the pre-authentication will expire.
>
> Pre-authentication retries: It is typically expected that shortly
> following the pre-authentication process, the mobile entity moves
> to the new point of attachment and converts the pre-authentication
> state to a full authentication state (the procedure for which is
> not the topic of this particular subsection). However, if the
> peer has yet not moved to the new location and realizes that the
> pre-authentication is expiring, it may perform another pre-
> authentication. In order to avoid unlimited number of pre-
> authentication tries, it is quite possible that the network policy
> sets a limit on the maximum number of pre-authentication attempts.
>
> SD> The last part of the above paragraph seems to provide a solution rather than issue while all other bullet point describe the issue only. Needs to be uniform across the draft.
OK.
>
> 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.
>
> Session Resumption: In case the peer ping pongs between a network
> N1 with which it has a full 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 life time and keying
> material caching needs to be dealt with.
>
> Multiple candidate authenticators: There may be situations where
> the mobile node may need to make a selection between a number of
> candidate attachment points. In such cases, it is desirable for
> the mobile to perform pre-authentication with multiple
> authenticators. In such cases the AAA server may need to be aware
> of the situation.
>
> Roaming support: In case the pre-authentication is being performed
> through a serving network that is foreign to the MN's home AAA
> server, the AAA server needs to obtain the information about the
> serving network in addition to the information about the candidate
> network, so that the AAA server can make authorization decisions
>
> SD> Is not correct that this information will be available to the home AAA when MN first attaches a foreign network in the first place?
This is a good point. I think you are right. Perhaps we can remove
this bullet.
>
> accordingly, e.g., depending on the authorization policy, the home
> AAA server may not allow pre-authentication via a particular
> serving network.
>
> Inter-technology support: Current specifications on pre-
> authentication mostly deal with homogeneous 802.11 networks. The
> AAA attributes such as Calling-Station-ID [I-D.aboba-radext-wlan]
> may need to be expanded to cover other access technologies.
> Furthermore, heterogeneous handovers may require a change of the
> MN identifier as part of the handover. Investigation on the best
> type of identifiers for MNs that support multiple access
> technologies is required.
>
> Network controlled handovers: It is becoming quite common for the
> network operators to maintain the control over the handovers for
> various reasons including load balancing and performance. Hence
> the network may need to direct the MN to perform pre-
> authentication to a set of candidate authenticators in an
> anticipation for a handover. The AAA protocol extensions for
> carrying out such procedures need to be provided.
>
> SD> Not clear how the above is related to AAA protocol extensions. This could be handover policy and may be obtained via different means.
I agree that network controlled handover is more general than
pre-authentication. We can remove this bullet.
>
>
> 7. Security Considerations
>
> Since pre-authentication described in this document needs to work
> across multiple authenticators, any solution for this problem needs
> considerations on the following security threats.
>
> 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.
>
> SD> Again the last part provides a solution not an issue?
This part is describing a guidance (solution) to mitigate an attack.
As far as I understand, Security Considerations section can contain a
guidance.
>
> 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, when
> normal authentication uses link-layer EAP transport,
>
> SD> The statement ?when normal authentication uses link-layer EAP transport,?
> may be redundant.
I agree, we can remove the statement.
>
> 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.
>
>
Thanks,
Yoshihiro Ohba
_______________________________________________
HOKEY mailing list
HOKEY at ietf.org
https://www.ietf.org/mailman/listinfo/hokey