Internet DRAFT - draft-hewett-sipping-cal
draft-hewett-sipping-cal
SIP WG J. Hewett
Internet-Draft Cisco Systems
Intended status: Standards Track V. Gurbani
Expires: August 27, 2007 Bell Laboratories, Alcatel-Lucent
F. Audet
Nortel Networks
February 23, 2007
Confidential Access Levels for the Session Initiation Protocol (SIP)
draft-hewett-sipping-cal-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This specification defines a header for indicating the
confidentiality level established between the involved parties.
Hewett, et al. Expires August 27, 2007 [Page 1]
Internet-Draft Confidential Access Levels for SIP February 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Fixed Mode . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Variable Mode . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Resolving Access Levels . . . . . . . . . . . . . . . . . 5
3.4. Resolving Mixed Mode Access Levels . . . . . . . . . . . . 6
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Confidential Access Level Header . . . . . . . . . . . . . 6
4.2. The secure-access-level Option Tag . . . . . . . . . . . . 8
4.3. 418 Response Code . . . . . . . . . . . . . . . . . . . . 8
5. UAC Procedures . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Processing a Request . . . . . . . . . . . . . . . . . . . 8
5.2. Processing a Response . . . . . . . . . . . . . . . . . . 8
6. Proxy Procedures . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Processing a Request . . . . . . . . . . . . . . . . . . . 9
6.2. Processing a Response . . . . . . . . . . . . . . . . . . 9
7. UAS Procedures . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Successful CAL Session Establishment . . . . . . . . . . . 11
8.2. CAL Rejection . . . . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Hewett, et al. Expires August 27, 2007 [Page 2]
Internet-Draft Confidential Access Levels for SIP February 2007
1. Introduction
When sensitive and confidential communications are required in SIP
[RFC3261], a mechanism is needed by which each participant can be
assured of the confidentiality level established between the involved
parties. The notion of confidentiality presented here refers to both
the user agent (UA) devices and all transited network connections
between them. By establishing a level of trust in the session,
pariticpants are free to communicate at a level that is appropriate
for the sensitivity of the information being shared. There are
numerous examples for the need of such a mechanism including the
protection of sensitive information by corporate executives,
financial institutions, national security and miltary organizations.
We note that the level of trust discussed here is orthogonal to what
is normally associated with channel encryption and authentication
schemes like Transport Layer Security (TLS). While TLS encrypts the
stream and provides authentication indication of the connected peer,
it does not indicate the level of authorization of the connected
party; i.e., is the connected party someone with an executive
privilege, or does the connected party possess top-secret clearence,
for instance.
There are two areas of trust to consider for the establishment of
session confidentiality. The first is the UA itself and the
authorization of that device for a particular individual. Although
no mechanism is specified in this document, some type of user
authentication to a device is assumed. Many methods can be used,
ranging from physical access restrictions in which the devices
themselves are under lock and key to identity management systems that
use elements such as biometric authentication to enable the device at
the appropriate confidentiality level.
The second aspect of trust is the interconnecting facilities between
the caller and callee. Both the signaling and media planes are
considered with respect to trusted facilities. The signaling session
may transit SIP proxies and interconnecting network components before
terminating to the callee. Each proxy must consider the level of
trust associated with the next signaling hop.
This document deals only with format and exchange of a header to the
SIP signaling messages that indicates the confidentiality level
established between the involved parties. It assumes that the user
has been authorized to use a device, and furthermore, that a proxy is
configured with appropriate confidentiality levels to allow it to
service an incoming request appropriately.
Hewett, et al. Expires August 27, 2007 [Page 3]
Internet-Draft Confidential Access Levels for SIP February 2007
2. Terminology
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 [RFC2119].
3. Overview
There are two modes of operation for establishing the confidentiality
level: fixed mode and variable mode. Fixed mode enforces a specific
level of confidentiality whereas variable mode resolves to a specific
access level based on the values offered by participating entities.
When a specific confidentiality level must be established, fixed mode
is the preferred method. When a level of confidentiality is desired
but call completion is more essential, variable mode is used.
Each UA uses an assigned Confidential Access Level (CAL) mode and
value while a proxy has a CAL mode and value associated with the
chosen network domain for routing. This means that a proxy or UA may
receive a mode that is different than what they are configured for.
This is permissible and resolution of the access level will be
handled as described later in this section.
CAL is processed in both the request path and the response path by
updating two separate access level values. For example, an INVITE
will contain a CAL whose access level is updated as it is processed
in the forward direction and a 200 OK to the INVITE will contain a CAL
with the second access level being updated in the backwards
direction. The 200 OK for the INVITE will transport the value
originated by the UAS and resolved in the response path as well as
the "reflected" access level. The reflected access level is the
value that was resolved in the forward direction and indicates the
final resolved level at the UAS. By having both access level values
returned to the caller, the UAC has the answer to the offered access
level returned in the reflected-access-level as well as an offer of
what can be supported by the UAS. The reflected-access-level
received by the UAC determines the access level presented to the
caller. However, an implementation MAY use the local-access-level
returned by the UAS in conjunction with the reflected-access level to
make its' final determination. It is beneficial for the UAC to
understand what can be supported by the UAS, particularly in
scenarios such as adhoc conferences where the access level may need
to be renegotiated due to callers joining or leaving a call.
Providing the local-access-level in the response message provides
this benefit.
The access level value of 0 SHALL be reserved to indicate that no
Hewett, et al. Expires August 27, 2007 [Page 4]
Internet-Draft Confidential Access Levels for SIP February 2007
confidentiality has been established and is only valid when using
variable mode. This is useful for cases where the access levels
could not be resolved to any confidential level but it is still
desirable to complete the call.
3.1. Fixed Mode
Fixed mode is a more restrictive and simpler means of establishing
calls. It is used when communication must occur at a particular
level of confidentiality. When a call is attempted at the specified
access level, each proxy as well as the destination UA must be able
to support that level of confidentiality. A comparison is made of
the access level being offered in the SIP request to the access level
that the proxy or UA processing the request is able to grant. If the
proxy or UA cannot provide the requested level of confidentiality, a
response code of 418 MUST be returned.
3.2. Variable Mode
Variable mode allows the caller to offer a desired CAL, which may get
modified by each proxy and the called UA to a level that can be
supported by each processing entity. Each proxy or UA must provide a
mechanism to resolve a new CAL value when using variable mode.
3.3. Resolving Access Levels
Access level values are used programatically by each UA or proxy
involved in the session to provide a resolved value based on the
combination of the incoming access level value and a locally
configured value. For fixed mode, a simple equality comparison is
made between the received value and the locally configured value.
Variable access levels are not intended to be compared numerically to
determine if one value is higher than another.
When variable mode is used, an incoming access level must be resolved
against a locally configured value to provide a result. An example
implementation might render this in the form of an x-y matrix vector
where the x value is taken from the incoming header, the y value is
taken from the locally configured value for the destination resource
and the vector is the resolved value. The actual implementation may
be done in different ways but should allow the flexibility of having
programmable results based on the intersection of incoming access
level and configured access level.
For example, an incoming CAL header using variable may contain a
value of 2 and the receiving proxy or UA may have a locally
configured value of 6. The resolved value could by any valid agreed
upon access level. The administrator may choose a value of 2 if
Hewett, et al. Expires August 27, 2007 [Page 5]
Internet-Draft Confidential Access Levels for SIP February 2007
using ascending priority values since 2 is the highest common
denominator. However, the actual values are left to the discretion
of the administrator rather than specified by this document. The use
of resolution vectors rather simple numerical ordering mandates
agreement between SIP processing entities on configured resolution
values.
Refer to section 3.4 for resolving access levels where the access
mode being requested does not match the mode configured,
3.4. Resolving Mixed Mode Access Levels
A proxy or UA may receive a CAL header with a mode that is different
than the locally configured mode. When a different mode is received,
the resulting mode must always be "fixed" since a fixed mode value
cannot be changed. For example, consider a UA that is configured as
variable and the received CAL mode is a fixed access level of 10.
The resolved value must be a fixed value of 10 to match the incoming
fixed value of 10 in order for the session to be successfully
established.
The same negotiation rules extend to scenarios involving
supplementary services such as transfer and conferencing. For
example, when a conference is established, each new participant
joining the conference MUST go through access resolution to determine
if the participant is allowed to join. If the existing conference or
the new participant uses fixed mode access, it is necessary to
resolve to fixed mode along with the predetermined access level in
order to establish the session.
4. Protocol Details
We now specify the related headers and response code.
4.1. Confidential Access Level Header
The CAL header may appear in a SIP request or response, and indicates
the need for secure and confidential communications. The CAL header
is a new SIP header that conveys the mode and level of
confidentiality that is desired for the session being established.
The syntax of the CAL header is defined as follows.
Hewett, et al. Expires August 27, 2007 [Page 6]
Internet-Draft Confidential Access Levels for SIP February 2007
Confidential-Access-Level = "Confidential-Access-Level" HCOLON
local-access-level SEMI
reflected-access-level
local-access-level = (access-level SEMI access-mode)
reflected-access-level = ("ref" EQUAL access-level SEMI
reflected-mode)
access-level = (1*2DIGIT ; 0 to 99)
access-mode = ("mode" EQUAL mode-param)
reflected-mode = ("rmode" EQUAL mode-param)
mode-param = (fixed / variable)
The following are examples, showing the Confidential-Access-Level
header.
Confidential-Access-Level: 4;mode=variable;ref=2;rmode=fixed
Confidential-Access-Level: 50;mode=variable;ref=40;rmode=variable
Confidential Access Level Header
The access-level indicates the confidentiality level of the session.
The access-mode indicates whether the fixed or variable method is
used. The local-access-level is used to indicate CAL for the path
over which the header is being transported. The relfected-access-
level provides to the UAC the final value resolved in the request
path to UAS. The reflected-mode indicates to the UAC the mode being
using by the UAS.
The Confidential-Access-Level header is supported in the following
request messages: INVITE [RFC3261], UPDATE [RFC3311].
The Confidential-Access-Level header is to be supported in the
following response messages: 200 (OK), 418 (Incompatible CAL). The
local-access-level of the CAL header in a 418 response contains the
CAL value of the routing domain at the proxy or the CAL value of the
device at the UAS, depending on where the 418 is generated.
The following table extends the values in table 2 of [RFC3261].
Header Field Where Proxy INV UPD
-----------------------------------------------------
Confidential Access Level R mr o o
Confidential Access Level 200 mr o o
Summary of header fields
Hewett, et al. Expires August 27, 2007 [Page 7]
Internet-Draft Confidential Access Levels for SIP February 2007
4.2. The secure-access-level Option Tag
This document defines the confidential-access-level option-tag. The
confidential-access-level option-tag MUST be included in the Require
header and in the Proxy-Require header when CAL is required for a
session.
4.3. 418 Response Code
If a proxy or UAS cannot resolve to a valid CAL value in a request
and determines that the call should not continue, a 418 response code
MUST be returned to the requestor. This response code indicates that
when the offered CAL value and the locally configured CAL value were
resolved, a decision was made to not allow the session to be
established. The decision to reject a call is based on the locally
administered policy, which is not specified by this document.
The 418 response SHOULD contain the CAL header with the reflected-
access-level set to the last successfully resolved value in the
request path. The local-access-level SHOULD be set to the access-
level supported by the UAS or to the access-level supported for the
routing domain that failed resolution at a proxy.
5. UAC Procedures
While CAL is generally established at call setup, a change in the
media path may require the access level to be upgraded or downgraded.
A re-INVITE or UPDATE may be used to convey a different access level
for the new media path.
5.1. Processing a Request
The level of confidentiality assigned to a device is communicated via
the CAL header. This does not preclude different classifications
from being assigned to a device when the appropriate authorization
level has been granted for using the device at that level. The
header is included in an outgoing INVITE at initial call setup to
communicate the desired level at which the session should be
established. The inclusion of the 'confidential-access-level' option
tag MUST be included in both the Require and Proxy-require headers.
This is the only way to ensure that every segment of the session is
established at the appropriate access level.
5.2. Processing a Response
The CAL MUST be received from the UAS in a 200 response if the
request contained a CAL header. The CAL header will include two
Hewett, et al. Expires August 27, 2007 [Page 8]
Internet-Draft Confidential Access Levels for SIP February 2007
access values. The reflected-access-level should be indicated to the
caller. Again, displaying the name of the callee is recommended.
The reflected CAL value indicates what has been presented to the UAS
as the access level. The local-access-level in the response
indicates the initial value sent by the UAS, updated appropriately by
each proxy in the response path. The local-access-level received by
the UAC represents the level that can be supported by the UAS using
the path between the UAS and UAC. The form in which the name and
CAL level are presented to the user is not specified but left up to
the implementor's discretion. If a 418 response is received, an
appropriate indication should be given to the caller.
6. Proxy Procedures
Proxies must be able to recognize and process the CAL header.
Otherwise, integrity of the complete path cannot be guaranteed. Each
proxy MUST determine the trust level of the domain to which the
message is being sent.
6.1. Processing a Request
The CAL local-access-level in the incoming header is resolved against
the locally configured routing domain. The local-access-level value
and mode of the CAL header are updated based on the results. Refer
to section 3 for details on resolving access levels.
For fixed mode, if the access level being requested cannot be met, a
418 response MUST be returned. For variable mode, if the access
level can be resolved to an acceptable level, the local-access-level
of the CAL header is updated with the new value. The proxy MAY
return a 418 response if the CAL value cannot be resolved to an
acceptable value. If local policy determines that the call should
continue even though an acceptable access level could not be
resolved, the local-access-level value MUST be set to 0 in the CAL
header.
In variable mode, a forking proxy MAY use the same or different CAL
levels for each fork. In fixed mode, a forking proxy MUST use the
same CAL level as the incoming request for all branches.
6.2. Processing a Response
The local-access-level in the incoming CAL header of a 200 response
is resolved against the locally configured routing domain. The
local-access-level value and mode of the CAL header are updated based
on the results. Refer to section 3 for details on resolving access
levels. If the local-access-level cannot be resolved to an
Hewett, et al. Expires August 27, 2007 [Page 9]
Internet-Draft Confidential Access Levels for SIP February 2007
acceptable level in the response path, the proxy MUST set the local-
access-level to 0. A local-access-level of 0 in the response
indicates to the UAC that CAL could not be resolved to an acceptable
level in the response path.
When a forking proxy receives multiple responses from different
branches, it is responsible for aggregating the responses and
providing a single final response. When at least one branch is
successful, the forking proxy would normally forward the successful
response, as mandated by RFC3261.
When all the branches fail, the forking proxy is responsible for
aggregating the responses and providing a single final response. If
the responses are heterogeneous (i.e., not all response codes are the
same), the proxy will use the rules of RFC3261 to choose the best
response. Implementations confirming to this specification MUST
choose a response code of 418 if at least one of the forked branches
contained such a response code. This is to allow the recipient to
resubmit the request using a different CAL header value, if it so
wants to.
7. UAS Procedures
When a SIP request message is received with a Confidential-Access-
Level header, the UAS should first determine whether the received
access-mode is fixed or negotiable. If the mode is fixed, the UA
should determine if the local-access-level matches the configured CAL
value. If the CAL values do not match, this constitutes a CAL
incompatibility and a 418 response MUST be returned.
When a SIP request message is received with a Confidential-Access-
Level header and the access-mode is variable, the UAS MUST resolve
the access level by evaluating the value within the header and the
locally configured value. The resolved value will be placed in the
reflected-access-level of the CAL header to be sent in the response
message. The UAS MUST also resolve its' locally established CAL for
the device against the routing domain of the response path. If an
acceptable resolution is made, the resolved value is placed in the
local-access-level of the CAL header. If the UAS deems the two
values to be incompatible, it MAY send a 418 response code if local
policy determines that the call should not continue. If local policy
determines that the call should continue, the local-access-level
value MUST be set to 0 in the CAL header of the 200 response.
An indication of the access level should be given to the callee and
it is recommended that the calling name be provided as well.
Hewett, et al. Expires August 27, 2007 [Page 10]
Internet-Draft Confidential Access Levels for SIP February 2007
The CAL header must be returned in the final response to an INVITE
sent with a CAL header. If the offered mode was variable, the
returned mode may be changed to fixed mode. However, an initial
fixed mode cannot be changed. The access level is changed only if
the mode of the UAS is variable. Otherwise, the access level remains
the same since it cannot be changed for fixed mode.
8. Examples
8.1. Successful CAL Session Establishment
This example shows a session being initiated by a@A with a CAL of 50
in variable mode. Proxy A forwards the request after changing the
CAL to 40. Proxy B forwards the request after changing the CAL to
35. UA b@B responds with CAL 60. Proxy B forwards the response
with CAL 40. Proxy A forwards the response unchanged. The call is
established with a CAL of 35.
Hewett, et al. Expires August 27, 2007 [Page 11]
Internet-Draft Confidential Access Levels for SIP February 2007
a@A A B b@B
| | | (CAL=V60)
| | | |
| INVITE F1 | | |
|(CAL:50;v;r=0;v) | | |
|-------------------->| INVITE F3 | |
| | (CAL:40;v;r=0;v) | |
| |------------------>| INVITE F5 |
| | |(CAL:35;v;r=0;v) |
| 100 Trying F2 | |------------------>|
|<--------------------| 100 Trying F4 | |
| |<------------------| 100 Trying F6 |
| | |<------------------|
| | | |
| | | 200 OK F7 |
| | | (CAL:60;v;r=35;v) |
| | 200 OK F8 |<------------------|
| | (CAL:40;v;r=35;v) | |
| 200 OK F9 |<------------------| |
| (CAL:40;v;r=35;v) | | |
|<--------------------| | |
| | | |
| ACK F10 | | |
|-------------------->| ACK F11 | |
| |------------------>| ACK F12 |
| | |------------------>|
| | | |
-----------------------------------------------------------------
CAL Established at 35
-----------------------------------------------------------------
| | | |
Successful CAL Session Establishment
8.2. CAL Rejection
This example shows a session being initiated by a@A with a CAL of 40
in fixed mode. The request is accepted by proxy A and forwarded to
proxy B. Proxy B rejects the request with 418 because it cannot
support the requested CAL.
Hewett, et al. Expires August 27, 2007 [Page 12]
Internet-Draft Confidential Access Levels for SIP February 2007
a@A A B b@B
| | | (CAL=F30)
| | | |
| INVITE F1 | | |
| (CAL:40;f;r=0;f) | | |
|--------------------->| INVITE F3 | |
| | (CAL:40;f;r=0;f) | |
| |-------------------->| |
| 100 Trying F2 | | |
|<---------------------| 418 CAL Rejected F4 | |
| | (CAL:30;f;r=40;f) | |
| |<--------------------| |
| 418 CAL Rejected F5 | | |
|<---------------------| | |
| | | |
| ACK F6 | | |
|--------------------->| ACK F7 | |
| |-------------------->| |
| | | |
CAL Rejection
9. IANA Considerations
This section defines one new SIP header, one new SIP response code
and one new SIP option tag.
Header name: Confidential-Access-Level
Compact form: none
Option tag: 'confidential-access-level'
Descriptive text: Indicates support for the Confidential Access
Level.
Response code: 418
Default reason phrase: Confidential Access Level Rejected
10. Security Considerations
Confidentiality, as asserted by the use of CAL depends on the concept
of trusted domains. A trusted domain is the collection of proxies,
user agents and access network components that provide a complete
path from the calling UA to the called UA. When that path lies
completely within a private network, there is high degree of
confidence in the ability of the network to prevent access to
sensitive information communicated over a session. At the other end
Hewett, et al. Expires August 27, 2007 [Page 13]
Internet-Draft Confidential Access Levels for SIP February 2007
of the spectrum, transmission over the public internet provides a
much lower degree of confidence. Between these two extremes lie
interconnecting network agreements where service providers assure a
specified level of security in transit over their network.
When a request or response are sent with the CAL header, each SIP UA
or proxy must determine the trust level of the next SIP entity to
which they are sending to assess the confidentiality level.
11. Acknowledgments
Thanks to Gary Kelly, Jack Klecha, John Rutledge, Bill Maloid and
Cullen Jennings for their help in defining the solution and writing
this document.
12. References
12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
12.2. Informative References
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
UPDATE Method", RFC 3311, October 2002.
Authors' Addresses
Jeff Hewett
Cisco Systems
7025-2 Kit Creek Rd
Mailstop RTP2H/2/4
Research Triangle Park, NC 27709-4987
USA
Phone +1 919 392 2409
Email: jhewett@cisco.com
Hewett, et al. Expires August 27, 2007 [Page 14]
Internet-Draft Confidential Access Levels for SIP February 2007
Vijay K. Gurbani
Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane
Rm 9F-546
Lisle, IL 60532
USA
Phone: +1 630 224 0216
Email: vkg@alcatel-lucent.com
Francois Audet
Nortel Networks
4655 Great America Parkway
Santa Clara, CA 95054
US
Phone: +1 408 495 2456
Email: audet@nortel.com
Hewett, et al. Expires August 27, 2007 [Page 15]
Internet-Draft Confidential Access Levels for SIP February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hewett, et al. Expires August 27, 2007 [Page 16]
