Identity Representation for RSVP
RFC 3182
| Document | Type |
RFC - Proposed Standard
(October 2001; Errata)
Obsoletes RFC 2752
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 3182 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
Network Working Group S. Yadav
Request for Comments: 3182 R. Yavatkar
Obsoletes: 2752 Intel
Category: Standards Track R. Pabbati
P. Ford
T. Moore
Microsoft
S. Herzog
PolicyConsulting.Com
R. Hess
Intel
October 2001
Identity Representation for RSVP
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document describes the representation of identity information in
POLICY_DATA object for supporting policy based admission control in
the Resource ReSerVation Protocol (RSVP). The goal of identity
representation is to allow a process on a system to securely identify
the owner and the application of the communicating process (e.g.,
user id) and convey this information in RSVP messages (PATH or RESV)
in a secure manner. We describe the encoding of identities as RSVP
policy element. We describe the processing rules to generate
identity policy elements for multicast merged flows. Subsequently,
we describe representations of user identities for Kerberos and
Public Key based user authentication mechanisms. In summary, we
describe the use of this identity information in an operational
setting.
This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment
error and a field size definition error in ErrorValue in RFC 2752.
Yadav, et al. Standards Track [Page 1]
RFC 3182 Identity Representation for RSVP October 2001
1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
2. Introduction
RSVP [RFC 2205] is a resource reservation setup protocol designed for
an integrated services Internet [RFC 1633]. RSVP is used by a host
to request specific quality of service (QoS) from the network for
particular application data streams or flows. RSVP is also used by
routers to deliver QoS requests to all nodes along the path(s) of the
flows and to establish and maintain state to provide the requested
service. RSVP requests will generally result in resources being
reserved in each node along the data path. RSVP allows particular
users to obtain preferential access to network resources, under the
control of an admission control mechanism. Permission to make a
reservation is based both upon the availability of the requested
resources along the path of the data and upon satisfaction of policy
rules. Providing policy based admission control mechanism based on
user identity or application is one of the prime requirements.
In order to solve these problems and implement identity based policy
control it is required to identify the user and/or application making
a RSVP request.
This document proposes a mechanism for sending identification
information in the RSVP messages and enables authorization decisions
based on policy and identity.
We describe the authentication policy element (AUTH_DATA) contained
in the POLICY_DATA object. User process can generate an AUTH_DATA
policy element and gives it to RSVP process (service) on the
originating host. RSVP service inserts AUTH_DATA into the RSVP
message to identify the owner (user and/or application) making the
request for network resources. Network elements, such as routers,
authenticate request using the credentials presented in the AUTH_DATA
and admit the RSVP message based on admission policy. After a
request has been authenticated, first hop router installs the RSVP
Show full document text