draft-ietf-sipping-trait-authz-01.txt   draft-ietf-sipping-trait-authz-02.txt 
SIPPING WG J. Peterson SIPPING WG J. Peterson
Internet-Draft NeuStar Internet-Draft NeuStar
Expires: August 17, 2005 J. Polk Expires: August 5, 2006 J. Polk
Cisco Cisco
D. Sicker D. Sicker
CU Boulder CU Boulder
H. Tschofenig H. Tschofenig
Siemens Siemens
February 16, 2005 February 2006
Trait-based Authorization Requirements for the Session Initiation Trait-based Authorization Requirements for the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-sipping-trait-authz-01 draft-ietf-sipping-trait-authz-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance with have been or will be disclosed, and any of which he or she becomes
RFC 3668. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on August 17, 2005. This Internet-Draft will expire on August 5, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2006).
Abstract Abstract
This document lays out a set of requirements related to trait-based This document lays out a set of requirements related to trait-based
authorization for the Session Initiation Protocol. While some authorization for the Session Initiation Protocol. While some
authentication mechanisms are described in the base SIP authentication mechanisms are described in the base SIP
specification, trait-based authorization provides information used to specification, trait-based authorization provides information used to
make policy decisions based on the attributes of a participant in a make policy decisions based on the attributes of a participant in a
session. This approach provides a richer framework for session. This approach provides a richer framework for
authorization, as well as allow greater privacy for users of an authorization, as well as allow greater privacy for users of an
identity system. identity system.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Trait-based Authorization Framework . . . . . . . . . . . . . 5 3. Trait-based Authorization Framework . . . . . . . . . . . . . 5
4. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 7 4. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Settlement for Services . . . . . . . . . . . . . . . . . 7 4.1. Settlement for Services . . . . . . . . . . . . . . . . . 8
4.2 Associating Gateways with Providers . . . . . . . . . . . 8 4.2. Associating Gateways with Providers . . . . . . . . . . . 8
4.3 Permissions on Constrained Resources . . . . . . . . . . . 9 4.3. Permissions on Constrained Resources . . . . . . . . . . . 9
4.4 Managing Priority and Precedence . . . . . . . . . . . . . 10 4.4. Managing Priority and Precedence . . . . . . . . . . . . . 10
4.5 Linking Different Protocols . . . . . . . . . . . . . . . 10 4.5. Linking Different Protocols . . . . . . . . . . . . . . . 10
5. Trait-based Authorization Requirements . . . . . . . . . . . . 11 5. Trait-based Authorization Requirements . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2 Informative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
This document explores requirements of the Session Initiation This document explores requirements of the Session Initiation
Protocol [1] for enabling trait-based authorization. This effort Protocol [1] for enabling trait-based authorization. This effort
stems from the recognition that when SIP requests are received by a stems from the recognition that when SIP requests are received by a
User Agent Server (UAS), there are authorization requirements that User Agent Server (UAS), there are authorization requirements that
are orthogonal to ascertaining of the identity of the User Agent are orthogonal to ascertaining of the identity of the User Agent
Client (UAC). Supplemental authorization information might allow the Client (UAC). Supplemental authorization information might allow the
UAS to implement non-identity-based policies that depend on further UAS to implement non-identity-based policies that depend on further
skipping to change at page 7, line 49 skipping to change at page 8, line 5
emergency services network might indicate that a particular user has emergency services network might indicate that a particular user has
a privileged status as a caller. a privileged status as a caller.
4. Example Use Cases 4. Example Use Cases
The following use cases are by no means exhaustive, but provide a few The following use cases are by no means exhaustive, but provide a few
high-level examples of the sorts of services that trait-based high-level examples of the sorts of services that trait-based
authorization might provide. All of the cases below consider authorization might provide. All of the cases below consider
interdomain usage of authorization assertions. interdomain usage of authorization assertions.
4.1 Settlement for Services 4.1. Settlement for Services
When endpoints in two domains share real-time communications When endpoints in two domains share real-time communications
services, sometimes there is a need for the domains to exchange services, sometimes there is a need for the domains to exchange
accounting and settlement information in real-time. The operators of accounting and settlement information in real-time. The operators of
valuable resources (for example, PSTN trunking, conference bridges, valuable resources (for example, PSTN trunking, conference bridges,
or the like) in the called domain may wish to settle with the calling or the like) in the called domain may wish to settle with the calling
domain (either with the operators of the domain, or a particular domain (either with the operators of the domain, or a particular
user), and some accounting operations might need to complete before a user), and some accounting operations might need to complete before a
call is terminated. For example, a caller in one domain might want call is terminated. For example, a caller in one domain might want
to access a conference bridge in another domain, and the called to access a conference bridge in another domain, and the called
skipping to change at page 8, line 34 skipping to change at page 8, line 38
about how to settle with it. about how to settle with it.
An authorization assertion created by the calling domain could An authorization assertion created by the calling domain could
provide the called domain with an assurance that a user's account can provide the called domain with an assurance that a user's account can
settle for a particular service. In some cases, no further settle for a particular service. In some cases, no further
information may be required to process a transaction, but if more information may be required to process a transaction, but if more
specific accounting data is needed, traits could also communicate the specific accounting data is needed, traits could also communicate the
network address of an accounting server, the settlement protocol that network address of an accounting server, the settlement protocol that
should be used, and so on. should be used, and so on.
4.2 Associating Gateways with Providers 4.2. Associating Gateways with Providers
Imagine a case where a particular telephone service provider has Imagine a case where a particular telephone service provider has
deployed numerous PSTN-SIP gateways. When calls come in from the deployed numerous PSTN-SIP gateways. When calls come in from the
PSTN, they are eventually proxied to various SIP user agents. Each PSTN, they are eventually proxied to various SIP user agents. Each
SIP user agent server is interested to know the identity of the PSTN SIP user agent server is interested to know the identity of the PSTN
caller, of course, which could be given within SIP messages in any caller, of course, which could be given within SIP messages in any
number of ways (in SIP headers, bodies, or what have you). However, number of ways (in SIP headers, bodies, or what have you). However,
in order for the recipient to be able to trust the identity (in this in order for the recipient to be able to trust the identity (in this
instance, the calling party's telephone number) stated in the call, instance, the calling party's telephone number) stated in the call,
they must first trust that the call originated from the gateway, and they must first trust that the call originated from the gateway, and
that the gateway is operated by a known (and trusted) provider. that the gateway is operated by a known (and trusted) provider.
There are a number of ways that a service provider might try to There are a number of ways that a service provider might try to
address this problem. One possibility would be routing all calls address this problem. One possibility would be routing all calls
from gateways through a recognizable 'edge' proxy server (say, from gateways through a recognizable 'edge' proxy server (say,
'sip.mci.com'). Accordingly, any SIP entity that received a request 'sip.example.com'). Accordingly, any SIP entity that received a
via the edge proxy server (assuming the use of hop-by-hop mutual request via the edge proxy server (assuming the use of hop-by-hop
cryptographic authentication) would know the service provider from mutual cryptographic authentication) would know the service provider
whom the call originated. However, it is possible that requests from from whom the call originated. However, it is possible that requests
the originating service provider's edge proxy might be proxied again from the originating service provider's edge proxy might be proxied
before reaching the destination user agent server, and thus in many again before reaching the destination user agent server, and thus in
cases the originating service provider's identity would be known only many cases the originating service provider's identity would be known
transitively. Moreover, in many architectures requests that did not only transitively. Moreover, in many architectures requests that did
originate from PSTN gateways could be sent through the edge proxy not originate from PSTN gateways could be sent through the edge proxy
server. In the end analysis, the recipient of the request is less server. In the end analysis, the recipient of the request is less
interested in knowing which carrier the request came from than in interested in knowing which carrier the request came from than in
knowing that the request came from a gateway. knowing that the request came from a gateway.
Another possible solution is to issue certificates to every gateway Another possible solution is to issue certificates to every gateway
corresponding to the hostname of the gateway ('gateway1.mci.com'). corresponding to the hostname of the gateway
Gateways could therefore sign SIP requests directly, and this ('gateway1.example.com'). Gateways could therefore sign SIP requests
property could be preserved end-to-end. But depending on the public directly, and this property could be preserved end-to-end. But
key infrastructure, this could however become costly for large depending on the public key infrastructure, this could however become
numbers of gateways, and moreover a user agent server that receives costly for large numbers of gateways, and moreover a user agent
the request has no direct assurance from a typical certificate that server that receives the request has no direct assurance from a
the host is in fact a gateway just because it happens to be named typical certificate that the host is in fact a gateway just because
'gateway1'. it happens to be named 'gateway1'.
Trait-based authorization would enable the trait 'is a gateway' to be Trait-based authorization would enable the trait 'is a gateway' to be
associated with an assertion that is generated by the service associated with an assertion that is generated by the service
provider (i.e. signed by 'mci.com'). Since these assertions would provider (i.e. signed by 'example.com'). Since these assertions
travel end-to-end from the originating service provider to the would travel end-to-end from the originating service provider to the
destination user agent server, SIP requests which carry them can pass destination user agent server, SIP requests which carry them can pass
through any number of intermediaries without discarding cryptographic through any number of intermediaries without discarding cryptographic
authentication information. This mechanism also does not rely on authentication information. This mechanism also does not rely on
hostname conventions to identity what constitutes a gateway and what hostname conventions to identity what constitutes a gateway and what
does not - it relies on an explicit and unambiguous attribute in an does not - it relies on an explicit and unambiguous attribute in an
assertion. assertion.
4.3 Permissions on Constrained Resources 4.3. Permissions on Constrained Resources
Consider a scenario wherein two universities are making use of a Consider a scenario wherein two universities are making use of a
videoconferencing service over a constrained bandwidth resource. videoconferencing service over a constrained bandwidth resource.
Both universities would like to enforce policies that determine how Both universities would like to enforce policies that determine how
this constrained bandwidth will be allocated to members of their this constrained bandwidth will be allocated to members of their
respective communities. For example, faculty members might have respective communities. For example, faculty members might have
privileges to establish videoconferences during the day, while privileges to establish videoconferences during the day, while
students might not. Faculty might also be able to add students to a students might not. Faculty might also be able to add students to a
particular videoconference dynamically, or otherwise moderate the particular videoconference dynamically, or otherwise moderate the
content or attendance of the conference, whereas students might content or attendance of the conference, whereas students might
skipping to change at page 10, line 17 skipping to change at page 10, line 21
If the federation honored the traits "faculty", "staff", and If the federation honored the traits "faculty", "staff", and
"student", they could be leveraged to ensure appropriate use of the "student", they could be leveraged to ensure appropriate use of the
network resource between universities participating in the network resource between universities participating in the
federation. An assertion would then be attached to every request to federation. An assertion would then be attached to every request to
establish a session that indicated the role of the requestor. Only establish a session that indicated the role of the requestor. Only
if the requestor has the appropriate trait would the session request if the requestor has the appropriate trait would the session request
be granted. Ideally, these policies would be enforced by be granted. Ideally, these policies would be enforced by
intermediaries (SIP proxy servers) that are capable of inspecting and intermediaries (SIP proxy servers) that are capable of inspecting and
verifying the assertions. verifying the assertions.
4.4 Managing Priority and Precedence 4.4. Managing Priority and Precedence
There is a significant amount of interest in the Internet telephony There is a significant amount of interest in the Internet telephony
community in assigning certain calls a 'priority' based on the community in assigning certain calls a 'priority' based on the
identity of the user, with the presumption that prioritized calls identity of the user, with the presumption that prioritized calls
will be granted preferential treatment when network resources are will be granted preferential treatment when network resources are
scarce. Different domains might have different criteria for scarce. Different domains might have different criteria for
assigning priority, and it is unlikely that a domain would correlate assigning priority, and it is unlikely that a domain would correlate
the identity of a non-local user with the need for priority, even in the identity of a non-local user with the need for priority, even in
situations where domains would like to respect one another's situations where domains would like to respect one another's
prioritization policies. prioritization policies.
skipping to change at page 10, line 44 skipping to change at page 10, line 48
contrasted here with a hypothetical trait-based system. contrasted here with a hypothetical trait-based system.
An assertion created by a domain for a particular request might have An assertion created by a domain for a particular request might have
an associated 'priority' attribute. Recipients of the request could an associated 'priority' attribute. Recipients of the request could
inspect and verify the signature associated with the assertion to inspect and verify the signature associated with the assertion to
determine which domain had authenticated the user and made the determine which domain had authenticated the user and made the
priority assessment. If the assertion's creator is trusted by the priority assessment. If the assertion's creator is trusted by the
evaluator, the given priority could be factored into any relevant evaluator, the given priority could be factored into any relevant
request processing. request processing.
4.5 Linking Different Protocols 4.5. Linking Different Protocols
Cryptographic computations are expensive and computing authorization Cryptographic computations are expensive and computing authorization
decisions might require a lot of time and multiple messages between decisions might require a lot of time and multiple messages between
the entity enforcing the decisions and the entity computing the the entity enforcing the decisions and the entity computing the
authorization decision. Particularly in a mobile environment these authorization decision. Particularly in a mobile environment these
entities are physically separated - or not even in the same entities are physically separated - or not even in the same
administrative domain. Accordingly, the notion of "single sign-on" administrative domain. Accordingly, the notion of "single sign-on"
is another potential application of authorization assertions, and is another potential application of authorization assertions, and
trait-based authorization - a user is authenticated and authorized trait-based authorization - a user is authenticated and authorized
through one protocol, and can reuse the resulting authorization through one protocol, and can reuse the resulting authorization
skipping to change at page 11, line 46 skipping to change at page 12, line 4
authorization in SIP: authorization in SIP:
1. The mechanism MUST support a way for SIP user agents to embed an 1. The mechanism MUST support a way for SIP user agents to embed an
authorization assertion in SIP requests. Assertions can be authorization assertion in SIP requests. Assertions can be
carried either by reference or by value. carried either by reference or by value.
2. The mechanism MUST allow SIP UACs to deliver to an authorization 2. The mechanism MUST allow SIP UACs to deliver to an authorization
service those SIP requests that need to carry an assertion. The service those SIP requests that need to carry an assertion. The
mechanism SHOULD also provide a way for SIP intermediaries to mechanism SHOULD also provide a way for SIP intermediaries to
recognize that an assertion will be needed, and either forward recognize that an assertion will be needed, and either forward
requests to an authorization service themselves, or notify the requests to an authorization service themselves, or notify the
UAC of the need to do so. UAC of the need to do so.
3. Authorization services MUST be capable of delivering an assertion
to a SIP UAC, either by reference or by value. It MAY also be
possible for an authorization service to add assertions to
requests itself, if the user profile permits this (for example,
through the use of content-indirection as described in [4]).
4. Authorization services MUST have a way to authenticate a SIP UAC. 3. Authorization services MUST be capable of delivering an
assertion to a SIP UAC, either by reference or by value. It MAY
also be possible for an authorization service to add assertions
to requests itself, if the user profile permits this (for
example, through the use of content-indirection as described in
[4]).
4. Authorization services MUST have a way to authenticate a SIP
UAC.
5. The assertions generated by authorization services MUST be 5. The assertions generated by authorization services MUST be
capable of providing a set of values for a particular trait that capable of providing a set of values for a particular trait that
a principal is entitled to claim. a principal is entitled to claim.
6. The mechanism MUST provide a way for authorized SIP 6. The mechanism MUST provide a way for authorized SIP
intermediaries (e.g. authorized proxy servers) to inspect intermediaries (e.g. authorized proxy servers) to inspect
assertions. assertions.
7. The mechanism MUST have a single baseline mandatory-to- implement 7. The mechanism MUST have a single baseline mandatory-to-
authorization assertion scheme. The mechanism MUST also allow implement authorization assertion scheme. The mechanism MUST
support of other assertion schemes, which would be optional to also allow support of other assertion schemes, which would be
implement. One example of an assertion scheme is SAML [6]. optional to implement. One example of an assertion scheme is
SAML [6].
8. The mechanism MUST ensure reference integrity between a SIP 8. The mechanism MUST ensure reference integrity between a SIP
request and assertion. Reference integrity refers to the request and assertion. Reference integrity refers to the
relationship between a SIP message and the assertion authorizing relationship between a SIP message and the assertion authorizing
the message. For example, a reference integrity check would the message. For example, a reference integrity check would
compare the sender of the message (as expressed in the SIP compare the sender of the message (as expressed in the SIP
request, for example in the "From" header field value) with the request, for example in the "From" header field value) with the
identity provided by the assertion. Reference integrity is identity provided by the assertion. Reference integrity is
necessary to prevent various sorts of relay and impersonation necessary to prevent various sorts of relay and impersonation
attacks. Note that reference integrity MAY apply on a attacks. Note that reference integrity MAY apply on a per-
per-message, per-transaction, or per-dialog basis. message, per-transaction, or per-dialog basis.
9. Assertion schemes used for this mechanism MUST be capable of 9. Assertion schemes used for this mechanism MUST be capable of
asserting attributes and/or traits associated with the identity asserting attributes and/or traits associated with the identity
of the principal originating a SIP request. No specific traits of the principal originating a SIP request. No specific traits
or attributes are required by this specification. or attributes are required by this specification.
10. The mechanism MUST support a means for end-users to specify 10. The mechanism MUST support a means for end-users to specify
policies to an authorization service for the distribution of policies to an authorization service for the distribution of
their traits and/or attributes to various destinations. their traits and/or attributes to various destinations.
11. The mechanism MUST provide a way of preventing unauthorized 11. The mechanism MUST provide a way of preventing unauthorized
parties (either intermediaries or endpoints) from viewing the parties (either intermediaries or endpoints) from viewing the
contents of assertions. contents of assertions.
skipping to change at page 13, line 34 skipping to change at page 13, line 41
The distribution of authorization assertions requires numerous The distribution of authorization assertions requires numerous
security properties. An authorization service must be able to sign security properties. An authorization service must be able to sign
assertions, or provide some similar cryptographic assurance that can assertions, or provide some similar cryptographic assurance that can
provide non-repudiation for assertions. These requirements are provide non-repudiation for assertions. These requirements are
further detailed in Section 3. further detailed in Section 3.
7. IANA Considerations 7. IANA Considerations
This document introduces no considerations for the IANA. This document introduces no considerations for the IANA.
Appendix A. Acknowledgments
The authors thank Christopher Eagan for his valuable input.
8. References 8. References
8.1 Normative References 8.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002. Session Initiation Protocol", RFC 3261, May 2002.
[2] Bradner, S., "Key words for use in RFCs to indicate requirement [2] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997. levels", RFC 2119, March 1997.
8.2 Informative References 8.2. Informative References
[3] Peterson, J., "Enhancements for Authenticated Identity [3] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Management in the Session Initiation Protocol (SIP)", Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-peterson-identity-04 (work in progress), February draft-ietf-sip- identity-06 (work in progress), October 2005.
2005.
[4] Burger, E., "A Mechanism for Content Indirection in SIP [4] Burger, E., "A Mechanism for Content Indirection in SIP
Messages", draft-ietf-sip-content-indirect-mech-05 (work in Messages", draft-ietf-sip-content-indirect-mech-05 (work in
progress), October 2004. progress), October 2004.
[5] Peterson, J., "A Privacy Mechanism for the Session Initiation [5] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002. Protocol (SIP)", RFC 3323, November 2002.
[6] Organization for the Advancement of Structured Industry [6] Organization for the Advancement of Structured Industry
Standards, "Security Assertion Markup Language v1.0", November Standards, "Security Assertion Markup Language v1.0",
2002, <http://www.oasis-open.org>. November 2002, <http://www.oasis-open.org>.
Authors' Addresses Authors' Addresses
Jon Peterson Jon Peterson
NeuStar, Inc. NeuStar, Inc.
1800 Sutter St 1800 Sutter St
Suite 570 Suite 570
Concord, CA 94520 Concord, CA 94520
US US
Phone: +1 925/363-8720 Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
URI: http://www.neustar.biz/ URI: http://www.neustar.biz/
James M. Polk James M. Polk
Cisco Systems Cisco Systems
2200 East President George Bush Turnpike 2200 East President George Bush Turnpike
Suite 570 Suite 570
Richardson, TX 75802 Richardson, TX 75802
US US
EMail: jmpolk@cisco.com Email: jmpolk@cisco.com
Douglas C. Sicker Douglas C. Sicker
University of Colorado at Boulder University of Colorado at Boulder
ECOT 531 ECOT 531
Boulder, CO 80309 Boulder, CO 80309
US US
EMail: douglas.sicker@colorado.edu Email: douglas.sicker@colorado.edu
Hannes Tschofenig Hannes Tschofenig
Siemens AG Siemens AG
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich 81739 Munich 81739
Germany Germany
EMail: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
Appendix A. Acknowledgments
The authors thank Christopher Eagan for his valuable input.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 16, line 41 skipping to change at page 16, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 32 change blocks. 
76 lines changed or deleted 79 lines changed or added

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