draft-ietf-rap-rsvp-authsession-00.txt   draft-ietf-rap-rsvp-authsession-01.txt 
RAP Working Group L-N. Hamer RAP Working Group L-N. Hamer
Internet Draft B. Kosinski Internet Draft B. Gage
Expires September 31, 2001 B. Gage Expires April 31, 2002 M. Broda
Nortel Networks Nortel Networks
April 2001 B. Kosinski
University of Alberta
Hugh Shieh
AT&T Wireless
November 2001
Session Authorization for RSVP Session Authorization for RSVP
draft-ietf-rap-rsvp-authsession-00.txt draft-ietf-rap-rsvp-authsession-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as documents at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet- Draft Shadow Directories can be accessed at The list of Internet- Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
The distribution of this memo is unlimited. This memo is filed as The distribution of this memo is unlimited. This memo is filed as
<draft-ietf-rap-rsvp-authsession-00.txt>, and expires September 31, <draft-ietf-rap-rsvp-authsession-01.txt>, and expires April 31,
2001. Please send comments to the authors. 2002. Please send comments to the authors.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This document describes the representation of session authorization This document describes the representation of session authorization
information in the POLICY_DATA object [POL-EXT] for supporting information in the POLICY_DATA object [POL-EXT] for supporting
policy-based per-session authorization and admission control in policy-based per-session authorization and admission control in
skipping to change at page 6, line 50 skipping to change at page 6, line 50
authorizing entity. authorizing entity.
OctetString OctetString
Contains the authorizing entity credentials. Contains the authorizing entity credentials.
3.3.3 Session Identifier 3.3.3 Session Identifier
SESSION_ID is a unique identifier for this session. It may be used SESSION_ID is a unique identifier for this session. It may be used
for a number of purposes, including replay detection, or even for a number of purposes, including replay detection, or even
mapping this request to a policy decision entry made by the mapping this request to a policy decision entry made by the
authorizing entity. authorizing entity. The SESSION_ID can be based on simple sequence
number or on a standard NTP timestamp.
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| Length |S-Type |SubType| | Length |S-Type |SubType|
+-------+-------+-------+-------+ +-------+-------+-------+-------+
| OctetString ... | OctetString ...
+-------+-------+-------+-------+ +-------+-------+-------+-------+
Length Length
Length of the attribute, which MUST be >= 4. Length of the attribute, which MUST be >= 4.
Dependant on the environment, the session identifier will have
different lengths in order to ensure uniqueness during the
lifetime of a token (equal to the lifetime of the session).
We recommend using an octet string of a minimum of 32 bit, but
a value of 64 bit may be required in some environments.
S-Type S-Type
SESSION_ID SESSION_ID
SubType SubType
The following sub-types for SESSION_ID are defined. IANA The following sub-types for SESSION_ID are defined. IANA
SHALL act as a registry for SESSION_ID sub-types as described SHALL act as a registry for SESSION_ID sub-types as described
in section 7, IANA Considerations. Initially, the registry in section 7, IANA Considerations. Initially, the registry
contains the following sub-types of SESSION_ID: contains the following sub-types of SESSION_ID:
1 ASCII_ID Simple plain ASCII string identifier. 1 ASCII_ID Simple plain ASCII string identifier.
2 UNICODE_ID Simple plain UNICODE string identifier. 2 UNICODE_ID Simple plain UNICODE string identifier.
3 OCTET_ID Raw octet string identifier. 3 OCTET_ID Raw octet string identifier.
4 NTP_TIMESTAMP NTP Timestamp Format as defined in
RFC-1305.
OctetString OctetString
Contains the actual session identifier. Contains the actual session identifier.
3.3.4 Source Address 3.3.4 Source Address
SOURCE_ADDR is used to identify the source address specification of SOURCE_ADDR is used to identify the source address specification of
the authorized session. This S-Type MAY be useful in some scenarios the authorized session. This S-Type MAY be useful in some scenarios
to make sure the resource request has been authorized for that to make sure the resource request has been authorized for that
particular source IP address and/or port. particular source IP address and/or port.
skipping to change at page 13, line 32 skipping to change at page 13, line 32
Following the policies outlined in [IANA-CONSIDERATIONS], Following the policies outlined in [IANA-CONSIDERATIONS],
AUTH_ENT_ID, AUTH_ENT_CRED, SESSION_ID, START_TIME, STOP_TIME, AUTH_ENT_ID, AUTH_ENT_CRED, SESSION_ID, START_TIME, STOP_TIME,
SOURCE_IP, DEST_IP, RESOURCES and DIGITAL_SIGNATURE SubType values SOURCE_IP, DEST_IP, RESOURCES and DIGITAL_SIGNATURE SubType values
in the range 0-127 are allocated through an IETF Consensus action, in the range 0-127 are allocated through an IETF Consensus action,
SubType values between 128-255 are reserved for Private Use and are SubType values between 128-255 are reserved for Private Use and are
not assigned by IANA. not assigned by IANA.
8. Security Considerations 8. Security Considerations
The purpose of this draft is to describe a mechanism for media The purpose of this draft is to describe a mechanism for session
authorization to prevent theft of service. It does not cover other authorization to prevent theft of service.
possible security breaches such as IP spoofing.
In order to ensure that the integrity of the token is preserved in
some environments, the digital signature attribute SHOULD be used.
In fact, since the token is to be relayed through the end host,
which is usually considered untrusted, we strongly recommend the
use of the digital signature attribute.
Simple authentication (e.g. plain ASCII or UNICODE) does not
contain credential that can be securely authenticated and is
inherently less secured.
The Kerberos authentication mechanism is reasonably well secured.
Kerberos is more efficient than the PKI mechanism from
computational point of view.
PKI authentication option should provide highest level of
security and good scalability, however it requires infrastructure
support and may have performance impacts.
9. Acknowledgments 9. Acknowledgments
We would like to thank Francois Audet, Don Wade, Hamid Syed, Matt We would like to thank Francois Audet, Don Wade, Hamid Syed,
Broda, and many others for their valuable comments. Kwok Ho Chan and many others for their valuable comments.
In addition, we would like to thank S. Yadav, et al, for their In addition, we would like to thank S. Yadav, et al, for their
efforts on RFC 2752, as this document borrows heavily from their efforts on RFC 2752, as this document borrows heavily from their
work. work.
10. References 10. References
[I-REP] S. Yadav et al, "Identity Representation for [I-REP] S. Yadav et al, "Identity Representation for
RSVP", Internet-draft, RSVP", Internet-draft,
draft-ietf-rap-rsvp-newidentity-01.txt, draft-ietf-rap-rsvp-better-identity-00.txt,
January 2000 June 2001
[S-AUTH] Hamer, L-N. and Gage, B, "Framework for [S-AUTH] Hamer, L-N. and Gage, B, "Framework for
session setup with media authorization", session setup with media authorization",
Internet-Draft, Internet-Draft,
draft-hamer-rap-session-auth-00.txt, draft-hamer-rap-session-auth-02.txt,
February 2001. November 2001.
[ASCII] Coded Character Set -- 7-Bit American Standard [ASCII] Coded Character Set -- 7-Bit American Standard
Code for Information Interchange, ANSI X3.4- Code for Information Interchange, ANSI X3.4-
1986. 1986.
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in Writing an IANA Considerations Section in
RFCs", BCP 26, RFC 2434, October 1998. RFCs", BCP 26, RFC 2434, October 1998.
[POL-EXT] Herzog, S., "RSVP Extensions for Policy [POL-EXT] Herzog, S., "RSVP Extensions for Policy
skipping to change at page 14, line 46 skipping to change at page 14, line 46
[RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S. [RFC-2205] Braden, R., Zhang, L., Berson, S., Herzog, S.
and S. Jamin, "Resource ReSerVation Protocol and S. Jamin, "Resource ReSerVation Protocol
(RSVP) - Version 1 Functional Specification", (RSVP) - Version 1 Functional Specification",
RFC 2205, September 1997. RFC 2205, September 1997.
[RFC-2209] Braden, R. and L. Zhang, "Resource ReSerVation [RFC-2209] Braden, R. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) - Version 1 Message Processing Protocol (RSVP) - Version 1 Message Processing
Rules", RFC 2209, September 1997. Rules", RFC 2209, September 1997.
[RFC-2327] Handley, M., Jacobson, V., "SDP: Session [RFC-2327] Handley, M., Jacobson, V., "SDP: Session
Description Protocol", RFC 2327, April 1998. Description Protocol", RFC 2327, October 1998.
[RFC-2396] Berners-Lee, T., Fielding, R., Irvine, U.C., [RFC-2396] Berners-Lee, T., Fielding, R., Irvine, U.C.,
Masinter, L., "Uniform Resource Identifiers Masinter, L., "Uniform Resource Identifiers
(URI): Generic Syntax", RFC 2396, August 1998. (URI): Generic Syntax", RFC 2396, August 1998.
[RFC-2474] Nichols, K., Blake, S., Baker, F., Black, D., [RFC-2474] Nichols, K., Blake, S., Baker, F., Black, D.,
"Definition of the Differentiated Services "Definition of the Differentiated Services
Field (DS Field) in the IPv4 and IPv6 Field (DS Field) in the IPv4 and IPv6
Headers", RFC 2474, December 1998. Headers", RFC 2474, December 1998.
skipping to change at page 15, line 33 skipping to change at page 15, line 33
ISO/IEC 9594-8 ISO/IEC 9594-8
11. Author Information 11. Author Information
Louis-Nicolas Hamer Louis-Nicolas Hamer
Nortel Networks Nortel Networks
Ottawa, Canada Ottawa, Canada
EMail: nhamer@nortelnetworks.com EMail: nhamer@nortelnetworks.com
Brett Kosinski Brett Kosinski
Nortel Networks University of Alberta
Ottawa, Canada Edmonton, Canada
EMail: brettk@nortelnetworks.com EMail: kosinski@cs.ualberta.ca
Bill Gage Bill Gage
Nortel Networks Nortel Networks
Ottawa, Canada Ottawa, Canada
EMail: gageb@nortelnetworks.com EMail: gageb@nortelnetworks.com
Matt Broda
Nortel Networks
Ottawa, Canada
EMail: mbroda@nortelnetworks.com
Hugh Shieh
AT&T Wireless
Redmond, USA
Email: hugh.shieh@attws.com
12. Full Copyright Statement 12. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. This Copyright (C) The Internet Society (2001). All Rights Reserved. This
document and translations of it may be copied and furnished to document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organisations, except as needed for the purpose of Internet organisations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into. followed, or as required to translate it into.
Expiration Date Expiration Date
This memo is filed as <draft-ietf-rap-rsvp-authsession-00.txt>, and This memo is filed as <draft-ietf-rap-rsvp-authsession-01.txt>, and
expires September 31, 2001. expires April 31, 2002.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/