NSIS
Internet Draft H. Tschofenig
Siemens
M. Buechli
S. Van den Bosch
Alcatel
H. Schulzrinne
Columbia U.
T. Chen
TU Berlin
Document:
draft-tschofenig-nsis-qos-authz-issues-00.txt
Expires: December 2003 June 2003
QoS NSLP Authorization Issues
<draft-tschofenig-nsis-qos-authz-issues-00.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
Various proposals for NSIS QoS NSLPs have been published recently.
The design of a QoS NSLPs has to consider more than only exchanging
QoS objects. Authorization has to be handled properly to make this
protocol both useful and performant. Authorization in mobile
environments, unfortunately, raises additional questions. This
document provides an introduction to the topic.
Tschofenig et al. Expires - December 2003 [Page 1]
QoS NSLP Authorization Issues June 2003
Table of Contents
1. Introduction..................................................2
2. Terminology...................................................3
3. Which entities are involved in computing the authorization
decision?........................................................3
4. How long is the authorization decision valid?.................6
5. What information is needed to compute the authorization decision?
.................................................................6
6. Authorization example based on RSVP...........................7
7. Security Considerations......................................10
8. Acknowledgments..............................................10
9. References...................................................10
Author's Addresses..............................................11
1. Introduction
Authorization is a necessary function in order to prevent theft-of-
service and to enable charging. With regard to authorization a few
issues still need to be resolved to specify the protocol interaction
for a QoS NSLP with regard to authorization of resource requests.
[Her95] and [Her96] give some hints about policy handling and
authorization in RSVP [RFC2205]. A number of papers have been
published in the meanwhile proposing numerous different procedures
for handling pricing, charging and even for including micro-payment
protocols. None of these proposals, however, plays a role today. To
avoid proposing many new alternative ways to handle authorization we
would like to draw the attention of the working group to this topic
in their effort to create a QoS NSLP.
With [TB+03] we tried to address the issues of authorization
although due to terminology most NSIS working group members have
probably not read the draft. Some others even think that these
issues are independently of the NSIS NSLP protocol itself.
We think that the following questions should be addressed during the
work on a QoS NSLP:
a) Which entities are involved in computing the authorization
decision?
b) How long is the authorization decision valid?
c) What information is needed to compute the authorization decision?
We will provide more details to these questions in the subsequent
sections.
Tschofenig et al. Expires - December 2003 [Page 2]
QoS NSLP Authorization Issues June 2003
It should be noted that the result of the authorization process
might be a "yes" or "no" decision or even a complex policy. In some
cases the latter might allow to answer further authorization
requests locally.
2. Terminology
This draft uses terminology described in [TB+03].
3. Which entities are involved in computing the authorization decision?
At an abstract level we have two different cases with regard to NSIS
signaling:
+-------------+ QoS request +--------------+
| Entity |----------------->| Entity |
| requesting | | authorizing |
| resource |granted / rejected| resource |
| |<-----------------| request |
+-------------+ +--------------+
^ ^
+...........................+
financial establishment
Figure 1: Two party approach
Figure 1 describes the simple and basic approach where
(a) the authorization decision is purely executed between the two
entities only or
(b) where previous (out-of-band) mechanisms separated the signaling
protocol from executing other entities during NSIS protocol
execution.
The entity authorizing the resource request and the entity actually
performing the QoS reservation are in the same administrative
domain. Hence they are treated as a single logical entity.
Examples for this type of model can be found between two neighboring
networks (inter-domain signaling) where a long-term contract (or
other out-of-band mechanisms) exists and allows both networks to
know
- how much a resource reservation costs
- how to charge the other entity (i.e. how the authorizing entity
finally gets paid for the consumed resources) and
- how to authorize the resource requesting entity (i.e. associating
the identifier of the protected signaling message to the identity
Tschofenig et al. Expires - December 2003 [Page 3]
QoS NSLP Authorization Issues June 2003
used in the authentication and key exchange protocol run and
finally this identity to the user identity of the contract for the
purpose of charging).
The consequence for an NSIS QoS NSLP protocol in this case is:
- No additional message signaling for authorization is required
- It might be necessary to include only some new objects.
- Triggering other protocols (such as credit control) might be
necessary but has no impact on the NSIS signaling machinery
It might also be possible to count micro-payment protocol approaches
to the two party case since it is a pure two party protocol. Fully
integrating a payment protocol into NSIS, however, requires
modifications to the NSIS protocol machinery itself since the
message flows of NSIS and the message flows of the payment protocol
might not be compatible.
Next a three party approach is presented which has two facets
whereby the first variant is shown in Figure 2 and the alternative
approach in Figure 3:
+--------------+
| Entity |
| authorizing | <...+
| resource | .
| request | .
+-----------+--+ .
^ | .
| | .
QoS | | QoS .
authz| |authz .
req.| | res. .
| | .
QoS | v .
+-------------+ request +--+-----------+ .
| Entity |----------------->| Entity | .
| requesting | | performing | .
| resource |granted / rejected| QoS | <..+
| |<-----------------| reservation | financial
+-------------+ +--------------+ settlement
Figure 2: Three party approach
The three party approach is considerably more complex since an NSIS
protocol has to enable the corresponding mechanisms to contact a
third party which executes the authorization request and (if
Tschofenig et al. Expires - December 2003 [Page 4]
QoS NSLP Authorization Issues June 2003
successful) establishes a financial settlement to the entity
providing the QoS reservation. The requesting entity is involved in
this three party approach since it has to authenticate itself to the
entity authorizing the request.
This type of configuration is common in mobility environments with
per-session authorization. Section 6 gives an example of per-session
authorization (per-session or even more often). Thereby a resource
request by the end host is send to an RSVP node in the local network
and then forwarded to the local PDP (via COPS). Since the local
domain is unable to verify the request it has to be forwarded to the
user's home network where authorization is provided. The response is
then returned and resources are granted (in case of a successful
authorization decision). The interaction between the visited network
and the home network establishes the necessary financial
infrastructure to latter charge the user for the consumed resources.
Authorization
Token Request +--------------+
+-------------->| Entity | financial settlement
| | authorizing | <..................+
| | resource | .
| +------+ request | .
| | +--------------+ .
| | .
| |Authorization .
| |Token .
| | .
| | .
| | .
| | QoS request .
+-------------+ + Authz. Token +--------------+ .
| Entity |----------------->| Entity | .
| requesting | | performing | .
| resource |granted / rejected| QoS | <..+
| |<-----------------| reservation |
+-------------+ +--------------+
Figure 3: Token based Three party approach
The token based three party approach is applicable in environments
where a previous protocol interaction is used to request
authorization tokens (or something similar) to assist the
authorization process at the entity performing the QoS reservation.
This approach can be found in solutions where OSP Tokens [OSP] are
or Authorization Tokens as used as described in [RFC3520] and in
[RFC3521].
Additionally to consider are the following questions:
Tschofenig et al. Expires - December 2003 [Page 5]
QoS NSLP Authorization Issues June 2003
- A resource request might be necessary between neighboring entities
only or between non-neighboring entities.
- Additionally of interest is whether authorization should be
provided to more than one entity along the path.
Both issues refer to the difference between the New Jersey Turnpike
and the New Jersey Parkway Model. See [TB+03] for a description of
the different trust models. Furthermore Section 6 of [TB+03] is of
interest when it comes to the question whether the sender or the
receiver should authorize a QoS request.
4. How long is the authorization decision valid?
For the NSIS QoS NSLP protocol machinery it is important to consider
at what frequency authorization decisions are made. Some possible
options are:
- Per request
(e.g. a request for more QoS resources than previously requested)
- Per session
(e.g. only during the initial setup of a QoS resource)
- Periodically
(authorization decision is repeated after a certain time interval)
- Event triggered
(as soon as something changes e.g. price changes due to mobility
which requires reauthorization)
The concept of a per-channel authorization (and financial
establishment) is introduced in [TB+03] and tries to move a three
party to a two party scenario by establishing the necessary
infrastructure outside NSIS and to thereby make it simpler. Thereby
it is possible to authorize QoS resource requests locally. The
feasibly of this approach heavily depends on assumptions.
If authorization is, however, provided based on the three party
approach then for example a periodically triggered re-authorization
request requires that the third party is contacted with every
authorization request. This might place a considerable burden onto
the QoS signaling protocol in a mobile environment.
5. What information is needed to compute the authorization decision?
Whenever an authorization decision has to be made then there is the
question which information serves as an input to the authorizing
Tschofenig et al. Expires - December 2003 [Page 6]
QoS NSLP Authorization Issues June 2003
entity. The following information items have been mentioned in the
past for computing the authorization decision (in addition to the
authenticated identity):
- Price
- QoS objects
- Policy rules
Policy rules include attributes like time of day, subscription to
certain services, membership, etc. into consideration when computing
an authorization decision.
Some of these information items are only available at certain
places. By, for example, relying on policy rules it is likely that
an authorization decision has to be made in the user's home network
since the network administrator might not be willing to disclose the
policies to other networks in order to offload the authorization
decision.
In case of QoS objects it might be fairly difficult for an
authorizing entity to grant a QoS authorization request since the
objects by themselves might not always allow inferring to the price
of the reservation. Hence in most cases it might be desirable to
provide additionally some price information (if not agreed between
the networks in advance).
6. Authorization example based on RSVP
This section illustrates a simple message flow based on the features
offered by RSVP. We assume a mobile environment where an end host is
attached to a network which is not his own home network. We do not
distinguish the case where the user has no home network and where
alternative means of access are used to authorize network access and
other resources. A short description of the two principal network
access authentication scenarios can be found in [Tsc03]. They are
also applicable for this discussion.
The description in [RFC3182], in [Her95] and in [Her96] gave us the
impression that RSVP aims to target authorization on the basis of an
individual RSVP message. Furthermore it seems that the New Jersey
Turnpike Model is the favorite model (although not directly
mentioned).
Figure 4 shows a typically message flow whereby the end host starts
with network access authentication before address configuration
occurs. Subsequently QoS signaling with RSVP starts with a PATH
message. The RSVP PATH message contains a Policy Object with a
Tschofenig et al. Expires - December 2003 [Page 7]
QoS NSLP Authorization Issues June 2003
digital signature (and the corresponding certificate) as proposed in
[RFC3182].
Visited Domain Home Domain
MN AR PDP/AAA PDP/AAA
| | | |
| Network Access Authentication |
|<======================================================>|
| | | |
| Address Config. | | |
|<================>| | |
| | | |
| RSVP Signaling | | |
| (PATH msg) | | |
|=================>| | |
| | COPS REQ | |
| |==================>| |
| | | |
| | | COPS REQ |
| | |================>|
| | | |
| | | COPS DEC |
| | |================>|
| | COPS DEC | |
| |<==================| |
| | | |
~ RSVP signaling ~ | |
| continues to | | |
| destination host | | |
Figure 4: RSVP Signaling Message Exchange with PDP Interaction
In [Tho02] it is suggested to delegate the authorization decision to
the local PDP and subsequently to the user's home PDP. This seems to
be necessary if an authorization decision has to be provided for
each individual session or even for each individual RSVP signaling
message. Verification of the digital signature might not help with
authorization in most environments.
The digital signature allows authentication of the client to the PDP
at the home network. Mutual authentication is not offered and replay
protection is most likely based on timestamps (although not
mentioned in [RFC3182]). In addition to the Policy Object it is also
necessary to forward information about the requested resources
otherwise an authorization decision by the user's home PDP is
worthless. Even then it is difficult for the PDP in the user's home
network to perform an authorization decision since the costs of the
reservation are most likely not known at this time. Since the
duration of the QoS reservation during reservation setup, the
Tschofenig et al. Expires - December 2003 [Page 8]
QoS NSLP Authorization Issues June 2003
authorization request/response scheme would have to be repeated
periodically. In this sender-authorizing scheme it is difficult to
determine how much resources will be actually reserved due to the
nature of the RSVP PATH message with its ADSPEC object and the
ability of the receiver to change the QoS reservation.
Public key based authentication between the user and his home
network would typically be used because
(a) user identity confidentiality is desired or
(b) if the user authenticates itself to the local network (and not
to the home network)
Since the public key based authentication proposed in [RFC3182] does
not provide (a) and scenarios for (b) do not require client based
public key based authentication it seems to be difficult to find a
motivation for using a performance intensive mechanism without an
additional benefit.
Clients today use a number of different authentication protocols
such as SRP, UTMS-AKA, etc. which offer different cryptographic
properties. In a mobile environment RSVP, together with COPS,
simulates functionality known from Radius and Diameter. It seems to
be unlikely that network operations add COPS for inter-domain
signaling only although Radius and Diameter already offers the same
functionality.
[RFC3182] also offers authentication based on a shared secret. For
entity authentication between the end host and the user's home
network this seems to be the most efficient approach although the
sequence number handling might not be the best replay protection
approach.
As with pk-based authentication and authentication based on
symmetric keys, Kerberos authentication to the PDP in the user's
home network does not provide session key distribution to the first
RSVP node in the visited network. To protect signaling messages a
session key for the RSVP Integrity object should be available. From
a performance point of view it is highly recommended to execute this
cross-realm authentication procedure only as frequently as
absolutely necessary due the high overhead. If Kerberos should be
additionally used to authenticate the user to the first RSVP node
then additional problems occur. Kerberos cross-realm authentication
does not match to AAA inter-domain handling. Several roundtrips
might be required to obtain the Ticket Granting Ticket of the
visited domain and finally the service ticket for either the PDP or
the first policy aware RSVP router.
Tschofenig et al. Expires - December 2003 [Page 9]
QoS NSLP Authorization Issues June 2003
In case of the New Jersey Turnpike Model authorization is only
provided between neighboring entities. For signaling messages which
are exchanged between neighboring domains it is not necessary to
perform per-session authorization by including a Policy Object.
Since the neighboring domains have long-term contracts and security
associations can easily be established data origin authentication is
provided by the RSVP Integrity Object. The identifier used to select
the key for the Integrity object can be associated with the identity
which allows authorizing the QoS request. Hence we argue that the
Policy Object should not be used for entity authentication between
neighboring networks due to the performance restrictions and the
presence of the RSVP Integrity object.
It should be noted that the policy control and the admission control
procedure perform different functions although they use similar
information. Both procedures might require information about the
requested resources (i.e. QoS objects). The admission control
procedure does not need to use user identity information or other
complex policy rules for deciding whether to grant a request or not.
The two entities executing the policy control and the admission
control procedure do not need to be co-located or even in the same
network. In the mobile scenario case it seems that admission control
is executed at the local network whereas policy control is provided
at the user's home network as part of the authorization procedure.
Most important for determining an authorization decision at the
user's home network is most likely a monetary amount - and not a QoS
object. In some cases it might be, however, possible for the PDP in
the user's home network to associate the cost of a QoS reservation
with the provided IntServ parameter.
7. Security Considerations
This document address authorization for QoS NSLPs and tries to raise
some questions about the expected functionality of this specific
application signaling protocol.
A definition of authorization in the QoS environment should be
created as part of a working group discussion to allow an NSLP
protocol to address the corresponding security requirements.
8. Acknowledgments
We would like to thank Allison Mankin for their comments to the NSIS
AAA draft. Her comments gave us the impression that we should work
on a shorter draft which raises the most important open issues.
9. References
Tschofenig et al. Expires - December 2003 [Page 10]
QoS NSLP Authorization Issues June 2003
[RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, and S.
Jamin, "Resource ReSerVation protocol (RSVP) -- version 1 functional
specification," RFC 2205, Internet Engineering Task Force, Sept.
1997.
[TB+03] H. Tschofenig, M. Buechli, S. Van den Bosch and H.
Schulzrinne: "NSIS Authentication, Authorization and Accounting
Issues", Internet Draft Internet Engineering Task Force, (work in
progress), March 2003.
[Her95] Herzog, S.: "Accounting and Access Control in RSVP",
Internet Draft Internet Engineering Task Force, (expired), November,
1995.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore,
T., Herzog, S., Hess, R.: "Identity Representation for RSVP", RFC
3182, October, 2001.
[Tho02] M. Thomas: "Analysis of Mobile IP and RSVP Interactions",
Internet Draft Internet Engineering Task Force, (work in progress),
October 2002.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore,
T., Herzog, S., Hess, R.: "Identity Representation for RSVP", RFC
3182, October, 2001.
[Her96] S. Herzog: "Accounting and Access Control for Multicast
Distributions: Models and Mechanisms", PhD Dissertation, University
of Southern California, June 1996, available at:
http://www.policyconsulting.com/herzog/cv.html.
[Tsch03] H. Tschofenig: "PANA Framework Issues", Internet Draft
Internet Engineering Task Force, January 2003.
[OSP] E. T. S. Institute, "Telecommunications and internet
protocol harmonization over networks (tiphon); open settlement
protocol (osp) for inter- domain pricing, authorization, and usage
exchange, technical specification 101 321. version 2.1.0."
[RFC3521] L. Hamer, B. Gage, and H. Shieh, "Framework for session
set-up with media authorization," RFC 3521, Internet Engineering
Task Force, April 2003.
[RFC3520] L. Hamer, B. Gage, B. Kosinski, and H. Shieh, "Session
Authorization Policy Element", RFC 3520, Internet Engineering Task
Force, April 2003.
Author's Addresses
Tschofenig et al. Expires - December 2003 [Page 11]
QoS NSLP Authorization Issues June 2003
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
EMail: Hannes.Tschofenig@siemens.com
Henning Schulzrinne
Dept. of Computer Science
Columbia University
1214 Amsterdam Avenue
New York, NY 10027
USA
EMail: schulzrinne@cs.columbia.edu
Sven Van den Bosch
Alcatel
Francis Wellesplein 1
B-2018
Antwerpen
Phone: 32-3-240-8103
EMail: sven.van_den_bosch@alcatel.be
Maarten Bchli
Alcatel
Francis Wellesplein 1
B-2018
Antwerpen
EMail: maarten.buchli@alcatel.be
Tianwei Chen
Technical University of Berlin
Sekr. FT 5-2, Einsteinufer 25
Berlin 10587
Germany
EMail: chen@ee.tu-berlin.de
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
Tschofenig et al. Expires - December 2003 [Page 12]
QoS NSLP Authorization Issues June 2003
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Tschofenig et al. Expires - December 2003 [Page 13]