Advanced Authentication and Authorization for Quality of Service

Download PDF
0 downloads 0 Views 959KB Size Report
Comment
useful, any QoS signaling protocol should provide a capa- bility for authentication and authorization of the QoS re- quests, especially in environments where the ...
To appear in Proc. of 1st IEEE Workshop on Security and QoS in Communication Networks (SecQoS 2005), Athens, Greence, Sept 2005

Advanced Authentication and Authorization for Quality of Service Signaling Tseno Tsenov, Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6, 81739 Munich, Germany Email: [email protected], [email protected] Xiaoming Fu University of G¨ottingen, Institute for Informatics Lotzestr. 16-18, 37083 G¨ottingen, Germany Email: [email protected]

Abstract One of the key requirements of today’s and future network infrastructures is to provide Quality of Service (QoS) support for end-to-end applications, by distinguishing the application flows and properly handling them in network nodes. As an important component to achieve Internet QoS, explicit signaling schemes for resource reservation have been proposed, which deal with admission, installation and refreshment of QoS reservation state information. To be useful, any QoS signaling protocol should provide a capability for authentication and authorization of the QoS requests, especially in environments where the end points are not trusted by the network nodes. However, existing protocols for QoS signaling encounter a number of authentication and authorization issues, which limit their application scenarios. The advent of NSIS QoS Signaling Layer Protocol (QoS-NSLP) offers the prospect to overcome some of these issues. After describing the overall design of QoSNSLP, we present an approach to support advanced authentication and authorization capabilities by using the Extensible Authentication Protocol (EAP). In comparison with existing approaches, this approach, combined with the support for effective interaction with the Authentication, Authorization and Accounting (AAA) infrastructure, provides flexible and extensible authentication and authorization methods for the QoS signaling.

1 Introduction In order to provide Quality of Service (QoS) for emerging real-time applications in the Internet, a number of necessary architectural changes to the Internet have been suggested. Most notably, the IETF has developed the IntServ

Eckhart K¨orner University of Applied Sciences Mannheim Windeckstr. 110, 68163 Mannheim, Germany Email: [email protected]

and DiffServ architectures [8, 9], by introducing flow- or class-based network resource control, including admission control, new packet queuing disciplines and scheduling algorithms other than just “best effort”. In order to make resource reservations in network nodes, a QoS signaling protocol is necessary. The Resource Reservation Protocol (RSVP), probably the best-known solution, has undergone extensive analysis and extensions since its basic specification [10] addressing various issues faced in different deployment scenarios. A series of IETF documents [16,18,28,29] define these extensions and also offer a framework for signaling message protection and authorization. Still, a few open issues need to be addressed. To learn from the past experience with RSVP and to revisit the protocol design principles, the IETF has formed the Next Steps in Signaling (NSIS) working group. The working group has developed a generic solution for pathcoupled signaling that also includes standardization of a QoS signaling protocol for resource reservation (QoSNSLP) [12]. NSIS adopts a layered signaling approach that includes [17]: • a number of application signaling protocols, namely the NSIS Signaling Layer Protocols (NSLPs), such as the NSIS QoS signaling protocol (QoS-NSLP), and • a common message transport layer, namely the NSIS Transport Layer Protocol (NTLP) [24], which handles common functions required by all signaling applications. Following the layered design in the NSIS signaling framework, security functions need to be supported in both layers. NTLP is responsible for message protection and node authentication between neighboring nodes. In addition, security mechanisms in general are needed in QoSNSLP.

QoS-NSLP supports several methods for user authentication and authorization of resource reservation requests, some of them similar to RSVP. The current QoS-NSLP specification relies on the policy control model where the authenticated identities provided by the underlying NTLP or authorization tokens are reused. The details of this exchange are described in [24]. In addition, interaction with the AAA infrastructure for an authorization decision on a QoS reservation request is considered to be supported. However, this approach requires integration of existing AAA protocols for flexible authentication, authorization, accounting and credit control, especially in a mobile environment. To fulfill the demand for supporting existing credentials and the large number of different scenarios, we propose to reuse the Extensible Authentication Protocol (EAP) [1] in the QoS-NSLP signaling sessions. EAP provides the following capabilities: • Flexible support for authentication and key exchange protocols. • Ability to reuse existing long-term credentials and already deployed authentication and key exchange protocols (for example, the UMTS-AKA [4]). • Integration into the existing AAA infrastructure, namely RADIUS [23] and Diameter [11]. • Ability to execute the authorization decision at the user’s home network based on the capabilities of protocols like RADIUS and Diameter. It should be noted that integrating EAP encapsulation into QoS-NSLP is more than just adding an object into the QoS-NSLP message exchange. Based on the suggested enhancement of supporting EAP based authentication and authorization for the QoS-NSLP we investigate the impact of the integration on the NSIS framework. In Section 2, initially we present the RSVP authorization framework. Considering the dependence of the proposed integration on the NSIS and EAP design, we continue with an overview of the NSIS protocol suite and EAP. As a part of the overview, in Section 2.3 we focus on the QoS-NSLP authorization features. In Sections 3 and 4 we discuss design approaches that result from the proposed integration of EAP into the NSIS framework.

RSVP. To provide authentication, integrity and replay protection, RSVP introduces hop-by-hop protection between the RSVP-capable network elements by using the built-in Integrity object [10]. This is based on a chain-of-trust between the RSVP routers where the security associations (SAs) are assumed to be available in advance. For authorization purposes, RSVP supports policy-based admission control, based on the credentials contained in the AUTH DATA element [28] of the POLICY DATA object within RSVP messages. User authorization might be provided by a plaintext identifier, by a Kerberos ticket or by a digital signature. Moreover, through interworking with the Common Open Policy Service protocol (COPS) [14], RSVP allows an RSVP router to delegate the authorization decision on the reservation requests to a third party Authorizing entity called Policy Decision Point (PDP). COPS is used for exchanging the policy information between the policy-aware RSVP nodes (called Policy Enforcement Points or PEPs) and PDP [18, 29]. A more detailed analysis of RSVP and its extensions can be found in [20]. A discussion of the security properties of RSVP can be found in [26].

2.2

The NSIS framework

The NSIS protocol suite is designed for various pathcoupled signaling purposes, including generic signaling services and application-specific signaling services. In the two-layer architecture, a major component in the NTLP is the General Internet Messaging Protocol for Signaling (GIMPS) [24]. NAT/Firewall NSLP QoS NSLP

NSLP

Metering NSLP GIMPS API

GIMPS (General Internet Messaging Protocol)

NSIS

Transport Layer Security

NTLP

UDP

TCP

SCTP

DCCP

IP Layer Security

IP

2 Related work Figure 1. NSIS Protocol Suite

2.1

RSVP authentication and authorization framework

A series of RSVP extensions form a framework offering security, authentication and authorization features for

Fig. 1 depicts the protocol stack inside an NSIS capable network element. The API between the two layers provides, in addition to the encapsulation and delivery of NSLP data, the exchange of parameters describing the transport

and security requirements of the NSLP protocol, or parameters used by GIMPS for the delivery of the NSLP message. When an NSLP layer protocol, such as QoS-NSLP, wishes to send a message it provides GIMPS with: • Message destination. • Message transmission requirements (e.g., concerning security and reliability). • An NSLP request/response payload carrying a resource request/response to be examined and responded to by nodes along the associated flow path supporting this NSLP. GIMPS provides a generic messaging layer, which uses one or more of the Internet transport protocols, additionally secured by Transport Layer Security (TLS) [13] or IP Security (IPsec). The IPsec architecture supports the dynamic establishment of IPsec security associations using IKEv1 and IKEv2. GIMPS handles common functions required by all signaling applications. In particular it is used to: • Discover the next NSIS peer along the path towards the data receiver that supports the requested NSLP functionality. The peer discovery message (called QUERY message in [24]) is sent to the data receivers address with the Router Alert Option (RAO) set [19, 21]. A RAO marked packet indicates to any NSIS aware node along the path to intercept and process the message, if it supports the indicated NSLP functionality. The QUERY message is routed based upon the nodes routing tables and as such follows the same path as the data traffic. • Establish (when required) a transport connection, called Messaging Association (MA) between neighboring peers to provide reliable and secured communication for signaling messages, and to maintain the association while it is in use. GIMPS offers to the NSLP layer two types of transport: • Datagram mode, which uses UDP encapsulation and offers unreliable and insecure transmission. • Connection mode, which provides reliable and optionally secure transmission over MAs between each two explicitly identified GIMPS adjacent peers. Existing transport protocols such as TCP or the Stream Control Transmission Protocol (SCTP) [25], in combination with TLS or IPsec, can be used. Messages will be delivered to the signaling application in the peer exactly once and in order or not at all. If there is a chance that the message was not delivered, an error will be returned to the signaling application.

Detailed descriptions of GIMPS message processing and packet format can be found in [24]. QoS-NSLP establishes and maintains state at nodes along the path of a data flow for the purpose of providing some forwarding resources for that flow. While GIMPS only signals between neighboring GIMPS nodes the QoSNSLP is responsible for the signaling communication along the entire path between the NSIS initiator and the NSIS responder. The design of QoS-NSLP is conceptually similar to RSVP, and uses soft-state refresh messages as the primary state management mechanism. It is more flexible than RSVP since it supports both sender- and receiver-initiated reservations, as well as a type of bi-directional reservation. Additionally, more than just the end-to-end signaling scenarios are supported. A distinction is made between the operation of the signaling protocol and the information required for the operation of the Resource Management Function (RMF). [5] describes the RMF-related information carried in the QoS Specification object (QSpec) in QoS-NSLP messages. The QSpec carries QoS specific objects, such as information about available and required resources, traffic descriptions and control information. A detailed specification of QoS-NSLP is provided in [12]. For the convenience of discussion we detail the authentication and authorization features of the protocol in Section 2.3.

2.3

Authorization approach in current QoS-NSLP specification

Following the layered design in the NSIS signaling framework, security functions need to be supported in both layers. QoS-NSLP relies to some extent on the security mechanisms provided by GIMPS, which utilizes existing authentication and key exchange protocols. In cases when GIMPS security and authentication services do not provide the required security level for QoS-NSLP messages, support of additional authentication and key exchange methods is desired for the QoS-NSLP. For example, this would be expected between the border of NSIS-capable network elements of different domains, when large amounts of resources need to be requested, when NSIS is used in pathdecoupled interactions with a bandwidth broker or when a per-reservation authorization has to be performed by the user’s home AAA server. The QoS-NSLP policy control is conceptually organized as illustrated in Fig. 2. It shows network elements through which application flows need to pass, a cloud of AAA servers and a Resource authorizing entity (i.e. Policy Decision Point - PDP). A resource request sent by the end host is intercepted at a router along the path. This router might delegate the authorization decision to the AAA infrastruc-

ture. The request will, for example, be routed to the home network, where the home AAA server will return a decision. Not all of the routers are policy-aware and policy enforcement is likely to be concentrated at the borders of an administrative domain. The input to policy control is referred to as ’policy data’, some of which the QoS-NSLP carries in the POLICY DATA object [12] while other information is provided across the GIMPS API. Policy data itself is opaque to the QoS-NSLP, which simply passes it to policy control when required. The policy data is independent from the QoS model in use. In some cases, signaling messages transmitted across the domain traverse an intermediate Policy Ignorant Node (PIN) that is able to process QoS-NSLP messages but does not handle policy information. The policy peering between ingress and egress edge of a domain therefore relies on the internal chain of trust between the nodes in the domain.

A recent proposal, the Diameter QoS application [2], provides the functional interaction of QoS-NSLP capable network elements with the AAA network. It replaces the usage of COPS for RSVP (Unfortunately as an AAA protocol, COPS has never received the same attention, from engineers and industry, as RADIUS or Diameter. Particularly, in a mobile environment where the authorization decision has to be provided by the user’s home network but not by the visited network, COPS usage is problematic due to the lack of inter-domain support. As a consequence, it is neither as widely deployed nor offering the same capabilities as RADIUS or Diameter.). In addition, Diameter QoS application aims at a flexible intra- or inter-domain authorization, accounting, credit control and deployment by exploring the features of the AAA infrastructure, which would naturally encompass business relationships such as those between network operators and third-party application providers. To take full advantage of the EAP integration it is necessary to use efficient (e.g., considering computation complexity, number of roundtrips, memory consumption) and secure EAP methods. A number of EAP methods have been proposed in the past that meet these criteria, such as EAPIKEv2 [27] or EAP-PSK [7].

2.4

Figure 2. QoS-NSLP Authorization architecture The QoS-NSLP policy control mechanism considers three approaches for user authentication and authorization required by resource reservation requests: • Reuse of authentication methods provided with GIMPS channel security mechanisms. • Usage of authorization tokens. • Encapsulation of EAP exchanges in the QoS-NSLP protocol. Only the first two approaches are actually supported by the current QoS-NSLP specification. The former two approaches introduce several functional or security restrictions and rely on a number of assumptions to hold in order to be useful. The authorization token approach, for example, requires another protocol that makes this token available to the end host and therefore to the QoS signaling protocol.

EAP Overview

EAP [1] is an authentication framework, which supports multiple authentication methods. The major feature of the EAP architecture is its flexibility. EAP authentication exchange runs between a peer and a server and EAP acts as a container for carrying EAP methods between these two entities. EAP permits the use of a backend authentication server whereby a pass-through device, called the Authenticator, is used to forward the EAP messages. Session keying material derived with EAP methods is then securely transported from the EAP server to the Authenticator for subsequent traffic protection. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. EAP is a “lock-step protocol”,i.e., the EAP authenticator waits to receive an EAP-Response before sending the next EAP-Request packet. This implies a certain inefficiency when handling fragmentation and reassembly. Therefore, if the lower layer supports fragmentation and reassembly, it may be preferable for fragmentation and reassembly to occur in the lower layer rather than in EAP. The authenticator handles retransmission of the EAPRequest packets until a valid EAP-Response packet is received from the peer, an optional retry counter expires or a lower level failure indication is received.

3 Extension of QoS-NSLP for EAP support

3.1

Based on the above review of related work, we believe EAP is a promising approach for providing authentication and authorization in the NSIS protocol suite. It provides strong and flexible cryptographic authentication support that aims to replace the currently provided one-shot authentication mechanisms. Since EAP allows reusing existing authentication protocols it could contribute to the adaptation of the QoS-NSLP signaling to even more deployment scenarios. For integrating EAP into QoS-NSLP we define a new policy element for the POLICY DATA object in QoSNSLP, the EAP policy element (EAP DATA) that carries EAP packets. The EAP session will be established between a QoS-NSLP initiator and a QoS-NSLP policy aware node (see Fig. 3). These nodes insert the EAP DATA policy elements into exchanged QoS-NSLP messages and are EAP peer and EAP authenticator in the session.

We investigate two approaches here. In the first one, the insertion of an EAP DATA policy element into a QoS-NSLP message does not require the transport service provided by GIMPS to be changed. This is implied by the fact that EAP requires only inorder delivery service from the underlying transport protocol. However, the condition for out-of-order delivery is two or more consequent EAP packets to be in transmission in the network at the same time. Then, considering that EAP is a “lock-step” protocol, this condition is very unlikely to happen and we could eliminate the in-order delivery requirement. The advantage of this approach is that no extension of the QoS-NSLP functionality is introduced. In addition to this, it tries to minimize the transmission delay by avoiding the C-mode connection establishment on the links where it is usually not required. On the other side, leaving the handling of fragmentation and retransmission to EAP will increase the number of exchanged QoS-NSLP messages that need to carry the EAP DATA policy elements. In addition, in most of the cases it is expected that a C-mode connection will be established anyway - either required by the QoS application (e.g. secured transport) or based on the GIMPS local settings. Other drawback is that fragmentation support on the NSLP layer increases the vulnerability to Denial of Service attacks (DoS). In particular, an attacker might flood a QoSNSLP node with messages, which need to be stored before verifying the correctness of the signaling message, thus exhausting the resources of the attacked node. Based on the presented analysis we conclude that this approach loads QoS-NSLP with functions that are not specific to it. In addition, identified drawbacks compensate the intended advantages and we do not favor it for a solution of the addressed issue. In the second approach, QoS-NSLP should request reliable transmission for the messages of the signaling session which involves EAP authentication and authorization. Reliable transport service provided by GIMPS utilizing TCP and SCTP protocols includes fragmentation and in-order delivery. Fragmentation support by the used EAP method is not necessary in this case, which will avoid an increase of the number of exchanged QoS-NSLP messages needed to carry the EAP DATA policy elements. We favor this approach to solve the investigated transport issue, but a specific case should be analyzed. It is caused by GIMPS functionality for MA establishment between two GIMPS peers. In particular, MA establishment may be initiated only by the requesting (upstream) peer. In the current context, this is relevant for the scenario in which GIMPS initially does not provide reliable transportation for

Figure 3. EAP exchange integration into QoS-NSLP session Other IETF protocols that decided to use EAP have analyzed some aspects of EAP integration already, such as PANA [15]. We reuse this experience and identified the following aspects that necessitate further investigation: 1. Transport requirements of EAP and their support by the NSIS framework. EAP itself is a container, and sets requirements on specific transport service features - fragmentation, reliability, in-order delivery and retransmission. 2. Seamless integration of EAP into the QoS-NSLP message processing. 3. Channel binding between the EAP authentication session and the lower layer security mechanism used by GIMPS. In this section we investigate each of these issues and propose solutions for them.

EAP Transport Requirements

the QoS-NSLP signaling session. This might happen if the QoS-NSLP initiator is initially not aware of EAP usage (does not include an EAP DATA policy element into the initial QoS-NSLP Reserve message) and does not request reliable transmission. Then, the QoS-NSLP policy aware node that receives the QoS-NSLP Reserve message might require EAP authentication and initiate an EAP-Request/Identity encapsulated into a QoS-NSLP message. This QoS-NSLP message should be sent over a reliable transport, which in this case is not available. To address this case we investigate two approaches: 1. A separate QoS-NSLP signaling session is initiated in the direction of the QoS initiator for handling the encapsulated EAP exchange (see Fig. 4). Then both signaling sessions are bound. However, introduction of an additional session makes this method unfavorable.

Figure 5. GIMPS connections modified for handling of QoS-NSLP session with EAP exchange

load on the functionality or the security aspects of the protocol. Therefore we adopt it in the next design considerations.

3.2

Figure 4. New QoS-NSLP session for handling EAP exchange

2. The QoS-NSLP message carrying EAPRequest/Identity is sent over the available transport offered by GIMPS to the NSLP initiator. In addition, no state would be installed in the QoS-NSLP policy aware node, which would not introduce DoS attack vulnerability (see Fig. 5). Consequently, the QoSNSLP initiator node requests reliable transportation for its QoS-NSLP message, which encapsulates the EAP-Response/Identity payload. As a result, the next QoS-NSLP messages carrying EAP DATA policy elements will receive the required transport service by GIMPS. At the GIMPS layer this might end up with establishment of a new MA with the required characteristics. Note that this is the worst case scenario since the MA between the QoS NSIS aware nodes might have been initially installed providing reliability depending on the local policy of the GIMPS layer at the affected nodes. The second approach smoothly integrates into the QoSNSLP signaling session and does not introduce additional

Seamless integration of EAP into the QoS-NSLP

Each of the two protocols, EAP and QoS-NSLP, has its message processing rules and state machines. Desired integration of both protocols might require adjustment or even extension of the QoS-NSLP message exchange. We investigate this issue, aiming at a seamless interworking of the protocols. EAP demands that each EAP-Request generates a response. The QoS-NSLP provides similar functionality by including a Request Identification Information object (RII) [12] into the QoS-NSLP Reserve/Query messages. This requires an explicit QoS-NSLP Response message to be sent. There are two possibilities to encapsulate the EAP DATA policy element into the QoS-NSLP. The EAP DATA may be included into the QoS-NSLP Reserve/Response messages or into the QoS-NSLP Query/Response messages. Here we take a combination of both for achieving our goal of seamless integration (see Fig. 6). The QoS-NSLP initiator sends a QoS-NSLP Reserve message, which carries an RII object and an EAP DATA policy element encapsulating the EAP-Identity packet. This message is received by the QoS-NSLP policy aware node, which saves the RII object and processes the EAP-Identity packet (by potentionally involving the AAA infrastructure). Subsequently, EAP-Requests from this node are encapsulated into QoS-NSLP Query messages, which include new RII objects. The QoS-NSLP initiator encapsulates corresponding EAP-Responses into QoS-NSLP Response mes-

Figure 6. GIMPS connections modified for handling of QoS-NSLP session with EAP exchange

sages, which carry the matching RII objects from the received QoS-NSLP Query messages. At the end of the EAP session, the QoS-NSLP policy aware node encapsulates the final EAP-Success packet into a QoS-NSLP Response message, together with the saved RII object from the initial QoS-Reserve message. Also, this QoS-NSLP Response message carries information for the final result of the QoS reservation signaling. This approach allows a seamless integration of the two protocols. Each explicit EAPResponse is encapsulated into a QoS-NSLP Response message, which matches the QoS-NSLP Query message encapsulating the EAP-Request packet. In addition, using QoSNSLP Query/Response messages allows retransmission of the EAP-Request and QoS-NSLP Query to be bound and handled by the QoS-NSLP policy aware node. In the case when no EAP-Identity is encapsulated into the initial QoS-NSLP Reserve message, the QoS-NSLP policy aware node replies with a QoS-NSLP Response message matching the RII object of the Reserve message and encapsulating an EAP-Identity/Request packet into the EAP DATA policy element. Then the message exchange continues as described above. This case is shown in Fig. 7.

3.3

Security

The aspect of authentication and authorization in the QoS environment has raised a number of security concerns in the past. The integration of EAP into the QoS-NSLP adds further aspects that need to be considered in addition to the transport and integration aspects discussed in previous sections. In subsequent sections we will investigate the aspects of channel and cryptographic bindings. 3.3.1 Cryptographic Binding Until recently, engineers and scientists thought that running one authentication and exchange protocol on top of another increases the security of the entire exchange. Running these two exchanges completely isolated may allow for Man-InThe-Middle (MITM) attacks, as shown in [6]. For example, when running EAP over TLS (as analyzed in [22]) the

two exchanges need to be cryptographically tied together. This can be accomplished using a number of ways including combining the session keys of both exchanges into additionally generated so called Compound Message Keys according to [22]. If GIMPS is secured by TLS and additional authentication and authorization is provided at the QoS-NSLP layer then the same MITM vulnerabilities need to be addressed. In the NSIS case, these two exchanges are handled at two different NSIS layers. Hence, additional security attributes need to be exchanged through the API between GIMPS and the QoS-NSLP. Currently, the GIMPS specification does not provide a strict API specification. Instead, a few clarifying hints to the implementers are given. Specifying additional security attributes, e.g., EAP method derived session keys to be pushed to the GIMPS layer, are therefore possible. This is, however, not the only obstacle: Exporting keying material from TLS or IKE/IPsec using standard mechanisms in order to combine it with the EAP method derived keying material to compute a Compound Message Key is difficult. Alternatively, if mutual authentication is provided with TLS to secure GIMPS signaling then the authenticated identities of both peers can be exchanged via the existing API definition and used to create a binding. This approach is described in details in the following Section 4. 3.3.2 Channel binding Another common problem for EAP is the validation of the authorization rights of the EAP Authenticator (QoS-NSLP policy aware node) that functions in pass-through mode. An adversary might identify itself to the EAP peer and the EAP server with a different identity or a different role. This vulnerability is known as the ’Lying NAS’ problem. For example, in the QoS-NSLP signaling case, an attacker might act as QoS-NSLP policy aware node and could misuse an EAP exchange to create the illusion for the EAP server that the context is different (e.g., wireless LAN access instead of wired access). Then a user, who is authenticated and authorized through the usage of EAP, might be charged for services that he has not received. In the currently discussed framework, EAP should be used to provide authentication and the session key as part of an AAA application, such as Diameter-QoS, which is responsible for providing the authorization decision, based on an EAP method that authenticates the user identity. This implies that a QoS-NSLP policy aware node should be authenticated and authorized to be one side in an AAA QoS Authorization session. In addition, the authorization decision is based not only on an authenticated identity, but also on the description of requested QoS parameters, which would clearly identify the type of the requested service. It should be noted that the second case is valid only if integrity

protection of the exchanged QoS data is available between the QoS-NSLP initiator and the Authorizing entity. In addition, the problem in general is identified and addressed by some EAP extensions, e.g., [3] or [27]. These solutions carry additional authorization related data between the EAP peer and EAP server. However, all above considerations that address the problem do not involve any change to the interworking between EAP and QoS-NSLP. 3.3.3 QoS-NSLP without GIMPS security In scenarios where no underlying GIMPS message protection is provided, QoS signaling data carried together with EAP DATA in the initial QoS-NSLP Reserve message, needs to be protected or verified for consistency by either the QoS-NSLP policy aware node or Authorizing entity. This could be done as part of the authorization process, by usage of the EAP derived session key that, depending on the scenario, is kept either in the Authorizing entity or provided to the QoS-NLPS Policy aware node.

4 Details on the EAP support for the QoSNSLP This section gives a more detailed description of the EAP support for the QoS-NSLP. Depending on whether the initiating peer requesting QoS authorization is initially aware of the possibility to use EAP or not, we outlined two scenarios in Section 3.1. Here, we consider the more comprehensive case, where the requesting peer is initially not aware of the EAP usage. To fill the EAP exchange with content we use the EAP-AKA method (that is used in the UMTS environment and described in [4]) for authentication and session key establishment. The message exchange can then be presented in six steps, as shown in Fig. 7: 1. Since the QoS-NSLP initiator node is not aware of usage of EAP, it might not request a reliable transport by GIMPS for the QoS-NSLP Reserve message. GIMPS will establish MAs between the QoS-NSLP aware nodes along the signaling path, which might provide only security but not reliability (for example, UDP protected by IPsec). 2. After reception of the QoS-NSLP Reserve message, the QoS-NSLP policy aware node must authorize the reservation request. In general, it should delegate the authorization decision to a third party Authorizing entity, contacted via the AAA infrastructure. Without loss of generality, here we delegate its functions to the QoS-NSLP policy aware node and focus on the QoS-NSLP and EAP exchange between the QoSNSLP initiator and QoS-NSLP policy aware node. In

order to authenticate the initiator of the QoS reservation request, the QoS-NSLP policy aware node uses an EAP method and responds with a QoS-NSLP Response message, carrying an EAP-Request/Identity. 3. The QoS-NSLP initiator sends a QoS-NSLP Reserve message carrying the EAP-Response/Identity requesting from GIMPS reliable transportation. At the GIMPS layer this might end up establishing new MAs with required characteristics along the signaling path to the QoS-NSLP policy aware node. All subsequent NSLP messages will be transmitted over these new MAs. 4. The subsequent EAP-Request packet, including AKAChallenge parameters, is encapsulated by the QoSNSLP policy aware node into a QoS-NSLP Query message. 5. The corresponding EAP-Response packet, including AKA-Challenge response attributes, is encapsulated by the QoS-NSLP initiator into a QoS-NSLP Response message. 6. A final EAP-Success packet is encapsulated into a QoS-NSLP Query message. Since here the EAP exchange is a part of an authorization process, further messages might need to be exchanged with payload, depending on the scenario, in order a final authorization decision to be provided. Considering the security issues that we identified in Sections 3.3.1 and 3.3.3, the results of the EAP method exchange (e.g., authenticated identities and session keys) are used to address them. 7. Subcase A. In the case of a secured channel established at the GIMPS layer, to ensure that both peers are aware of the two security sessions (e.g., GIMPS TLS and EAP session) an additional info is exchanged. Thus the QoS-NSLP initiator demonstrates its participation in the establishment of the GIMPS secured channel by using the EAP method derived session key to encrypt the identity it used into the GIMPS layer TLS Handshake with the QoS-NSLP policy aware node. The QoS-NSLP initiator sends the encrypted Identity (ID I) with a QoS-NSLP Response message to the QoS-NSLP policy aware node. This gives the ability to the QoS-NSLP policy aware node to match both Identities of the QoS-NSLP initiator (e.g., one authenticated in the GIMPS TLS exchange and the other received encrypted with the EAP method derived key) and verify that the QoS-NSLP initiator is its peer in both sessions. Formal analysis of the concept is provided in Appendix A.

fraudulent QoS-NSLP nodes is provided. An extended version of the solution proposed in [3] and in [27] would be required. Currently, the approach suggested in [3] and in [27] is limited to the identity of the NAS and does not consider quality of service or cost parameters.

5 Summary and Outlook

Figure 7. EAP based Authentication/Authorization exchange using EAP-AKA

Subcase B. In the case of no secured channel established at the GIMPS layer, the QoS signaling data is encrypted with the EAP method derived key and sent in the QoS-NSLP Response message to the QoS-NSLP policy aware node. 8. The QoS-NSLP policy aware node sends the final authorization decision in the QoS-NSLP Response message. In case the requesting node is aware of EAP usage and includes EAP-identity attributes into the initial QoSNSLP Reserve message, steps (1) and (2) should be skipped and proper transport connections should be established by GIMPS initially. For optimization, if the used EAP method allows, encrypted Initiator identity or QoS signaling data might be transmitted in the same QoS-NSLP messages as EAP exchange payload (step (5)) and thus steps (7A) / (7B) might be skipped. In this case, the final EAP-Success packet should be carried with the final authorization decision into a QoS-NSLP Response message in step (6). If the identities and parameters of the QoS exchange are transmitted betweeen the EAP peer and the EAP server protected inside an EAP method then further guarantees against

In this paper, we propose an extension of the features of QoS-NSLP for support of flexible authentication and authorization methods for QoS reservation requests. This is achieved by the integration of an EAP exchange into the QoS-NSLP signaling session. We have investigated the impact of this integration. These results combined with the support for effective interaction with the AAA infrastructure would provide flexible and extensible authentication and authorization methods for the QoS-NSLP protocol. The range of supported methods should allow seamless adaptation of the QoS-NSLP for deployment in present and future environments. It should be noted that this approach can lead to additional complexity in terms of NSIS node features, but in terms of protocol functionality it does not require an extension of the QoS-NSLP protocol message exchange procedure. Although the discussion in this document is limited to the QoS-NSLP protocol, the approach is also applicable to other NSIS NSLPs (such as the NAT/Firewall NSLP). As a next step in our work we plan to develop a prototype to evaluate the overhead and the performance of the proposed approach.

References [1] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, and H. Levkowetz. Extensible authentication protocol (eap). RFC 3748, 2004. [2] F. Alfano, P. McCann, and H. Tschofenig. Diameter quality of service application. Internet draft (draft-alfano-aaaqosprot-02), Work in Progress, 2005. [3] J. Arkko and P. Eronen. Authenticated service identities for the extensible authentication protocol (eap). Internet Draft (draft-arkko-eap-service-identity-auth-02), Work in Progress, 2005. [4] J. Arkko and H. Haverinen. Eap-aka authentication. Internet Draft(draft-arkko-pppext-eap-aka-15), Work in Progress, 2004. [5] J. Ash, A. Bader, and C. Kappler. Qos-nslp qspec template. Internet draft (draft-ietf-nsis-qspec-03), Work in Progress, 2005. [6] N. Asokan, V. Niemi, and K. Nyberg. Man-in-the-middle in tunnelled authentication protocols. Cryptology ePrint Archive, Report 2002/163, 2002. http://eprint.iacr.org. [7] F. Bersani and H. Tschofenig. The eap-psk protocol: a preshared key eap method. Internet Draft (draft-bersani-eappsk-07), Work in Progress, 2005.

[8] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. An architecture for differentiated service. RFC 2475, 1998. [9] R. Braden, D. Clark, and S. Shenker. Integrated services in the internet architecture: an overview. RFC 1633, 1994. [10] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin. Resource reservation protocol (rsvp) – version 1 functional specification. RFC 2205 (Proposed Standard) Updated by RFCs 2750, 3936, 1997. [11] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, and J. Arkko. Diameter base protocol. RFC 3588, 2003. [12] S. V. den Bosch, G. Karagiannis, and A. McDonald. Nslp for quality-of-service signaling. Internet draft (draft-ietf-nsisqos-nslp-06), Work in Progress, 2005. [13] T. Dierks and C. Allen. The tls protocol version 1.0. RFC 2246, 1999. [14] D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan, and A. Sastry. The cops (common open policy service) protocol. RFC 2748, 2000. [15] D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig, and A. Yegin. Protocol for carrying authentication for network access (pana). Internet Draft (draft-ietf-pana-pana-08), Work in Progress, 2005. [16] L.-N. Hamer, B. Gage, B. Kosinski, and H. Shieh. Session authorization policy element. RFC 3520, 2003. [17] R. Hancock, G. Karagiannis, J. Loughney, and S. Bosch. Next steps in signaling: Framework. RFC 4080, 2005. [18] S. Herzog. Cops usage for rsvp. RFC 2749, 2000. [19] D. Katz. Ip router alert option. RFC 2113, 1997. [20] J. Manner and X. Fu. Analysis of existing quality of service signaling protocols. RFC 4094, 2005. [21] C. Partridge and A. Jackson. Ipv6 router alert option. RFC 2711, 1999. [22] J. Puthenkulam. The compound authentication binding problem. Internet Draft (draft-puthenkulam-eap-binding04) , Work in Progress, 2003. [23] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote authentication dial in user service (radius). RFC 2138, 1997. [24] H. Schuzrinne and R. Hancock. Gimps: General internet messaging protocol for signaling. Internet draft (draft-ietfnsis-ntlp-05), Work in Progress, 2005. [25] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, T. Rytina, M. Kalla, L. Zhang, and V. Paxson. Stream control transmission protocol. RFC 2960, 2000. [26] H. Tschofenig and R. Graveman. Rsvp security properties. Internet Draft (draft-ietf-nsis-rsvp-sec-properties04.txt), Work in Progress, 2004. [27] H. Tschofenig, D. Kroeselberg, Y. Ohba, and F. Bersani. Eap ikev2 method (eap-ikev2). Internet Draft (draft-tschofenigeap-ikev2-05), Work in Progress, 2004. [28] S. Yadav, R. Yavatkar, R. Pabbati, T. Moore, S. Herzog, and R. Hess. Identity representation for rsvp. RFC 3182 (Proposed Standard), 2001. [29] R. Yavatkar, D. Pendarakis, and R. Guerin. A framework for policy based admission control. RFC 2753 (Informational), 2000.

A Formal method analysis In Section 3.3.1 we presented the vulnerability to MITM attacks of two authentication protocols running independently on top of each other. This security problem can be addressed by a cryptographical binding of both exchanges and the generation of so called Compound Message Keys according to [22]. The issue is relevant for our proposal where EAP exchange is run at the NSLP layer over GIMPS with a TLS secured channel. In addition to the difficultty to access the TLS or IKE/IPsec keying material required for generation of the Compound Message Keys, the GIMPS API must allow this information be exchanged. To avoid this complexity and in order not to introduce new GIMPS API extensions, we explored an alternative, i.e., TLS mutual authentication and provisioning of the authenticated identities to the NSLP layer over the GIMPS API. Indeed, the concept of encrypting the Initiator identity with the EAP method derived session key and transmitting it to the QoSNSLP policy aware node is described in details in Section 4 (steps (7.a) and (7.b)). Desired features of the proposed concept, such as authorization of the Initiator and mitigation of MITM attacks, have been verified by means of formal method analysis presented in this section.

A.1

Formal method analysis tools

We have used High Level Protocol Specification Language (HLPSL) - an expressive language for modeling communication and security protocols. We have used the tool OFMC (On-the-Fly Model-Checker), from the AVISPA project1 (“Automated Validation of Internet Security Protocols and Applications”), which uses a rich specification language for formalizing protocols, security goals, and threat models of industrial complexity.

A.2

Formal method model

To address the general authorization scenario we model three parties, as shown in Fig. 8: • QoS-NSLP initiator that is also TLS peer and EAP peer (referred as Client). • QoS-NSLP policy aware node that is also TLS peer, EAP authenticator and AAA client (referred as Router). • Authorizing entity that is also EAP server and AAA server (referred as Server). The model addresses security issues described in Sections 3.3.1 and 3.3.2, i.e., the MITM attack and the “Lying NAS” problem. Interworking of the different protocols 1 URL:

http://www.avispa-project.org

together makes an extensive modeling of each of the protocols (QoS-NSLP, EAP method, TLS and AAA protocol) challenging. In addition, the model focuses on the authorization aspect of the issues. Therefore to simplify it, we do not model the above protocols but directly use the services that their sessions provide.

Figure 9. Alice-Bob HLPSL notation

Figure 8. Formal method model The communication between the Router and the Client is over a TLS secured channel and the session between the Router and the Server is based on any AAA protocol. These protocols provide authentication, integrity and replay protection of the exchanged messages. The Client with its subscriber profile is known at the Server and authenticated via the EAP method exchange. For our analysis we make the following assumptions: • The Client and the Server have successfully executed an EAP method exchange and subsequently derive a symmetric session key for usage with this protocol (based on EMSK [1]). • The Client-Router communication over a TLS secured channel is modeled by a shared symmetric key between both peers. • We focus on the data origin authentication in order to model the trust between the end-parties participating in the AAA session and not usage of End-to-End security and encryption. To achieve this we use public keys for signing of the Server-to-Router messages. • Additionally, for better modeling of the TLS and AAA-protocol sessions, we include the identities of the session peers into the messages. “Alice-Bob” notation of the model with HLPSL syntacsis is illustrated in Fig. 9. Two authorization goals are modeled:

1. The Server provides to the Router a QoS authorization decision for the Client, which is based on Client’s authenticated identity (EAP ID Client in Fig. 8). The Router matches the authenticated identity of the Client (TLS ID Client, from the TLS-Handshake) with the identity (ID Client) provided by the Server in the authorization decision and mitigates the vulnerability to MITM attack. Note that the scenario presented in Section 4 is derived from the currently modeled general three party case. 2. The Client trusts that the Server checks if the Router is authorized to provide the service offered to the Client. QoS context is abstractly modeled by a parameter “Service” shared between the Router and the Server and provided by the Router to the Client. This mitigates misbehavior of the Router as “Lying NAS” but only in the aspect that it is authorized to provide QoS. Here, we assume that a Router, authorized to provide QoS, does not misbehave in order to obtain charging for QoS services not provided to the Client. The problem is general for QoS authorization solutions but not only local for the investigated case. EAP extensions proposed in [3] or [27] for carrying additional authorization related data in the EAP session between the client and the Server would address it. Since AVISPA does not provide direct proof of authorization, but only proof of authentication and secrecy, verification of the above goals is indirectly modeled. Mutual authentication between the Server and the Router and agreement on the identity of the Client, models verification of authorization of the Client. In addition, we introduce a shared parameter “Service” that is known by the Server and the Router. Authentication of the Client by the Server and mutual agreement on the value of the parameter “Service”,

models verification of the authorization of the Router. With introduced assumptions and simplifications, the model can not provide replay protection. However, such a protection is provided by the sessions of TLS, AAA protocol and EAP method and therefore only “weak authentication” is specified as goal of the AVISPA verification.

A.3

Formal method results

Results of the OFMC verifies that specified goals are met and no attack on the analyzed model are found.

Note that the current model mainly focuses on the MITM attack issue. In this context it has been extensively verified. More general authorization issues with QoS-NSLP, such as “Lying NAS” problem, are limited to the above assumptions, and thus only addressed to a certain extend. In order to fully address them, extensions of the present modeling approach are necessary but beyond the scope of this paper.