[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

   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 B’chli
   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]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/