SIP S. Fries
Internet-Draft Siemens AG
Intended status: Best Current H. Tschofenig
Practice Siemens Networks GmbH & Co KG
Expires: June 13, 2007 K. Fischer
Siemens Enterprise Communications
GmbH & Co KG
December 10, 2006
SIP Identity Usage BCP
draft-fries-sip-identity-usage-bcp-01.txt
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 June 13, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2006).
Fries, et al. Expires June 13, 2007 [Page 1]
Internet-Draft SIP Identity Usage BCP December 2006
Abstract
This document describes a use case for RFC4474 (SIP Identity) for
verifying a certificate that might not be publicly verifiable by
traditional means. It provides a best current practice document for
binding an identity to a certificate for the duration of a session.
The certificate may then be used to bootstrap further security
parameters, e.g., for securing media data. A discussion of possible
enhancements is included in the appendix. Editors Note: The first
version of this draft was discussed in the SIPPING WG. As the target
of this draft is a BCP for current issues, the draft was updated and
submitted to the SIP WG.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Existing Building Blocks . . . . . . . . . . . . . . . . . . . 6
4. Scenario and Profile . . . . . . . . . . . . . . . . . . . . . 7
4.1. Forward Credential Processing . . . . . . . . . . . . . . 7
4.2. Reverse Credential Processing . . . . . . . . . . . . . . 9
4.3. Usage Example . . . . . . . . . . . . . . . . . . . . . . 10
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Alternative Approaches . . . . . . . . . . . . . . . 17
A.1. Associating user identity and credentials upfront . . . . 17
A.2. Enhancements to SIP Identity using SIP SAML . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Fries, et al. Expires June 13, 2007 [Page 2]
Internet-Draft SIP Identity Usage BCP December 2006
1. Introduction
In current enterprise environments certificates are used to provide
secure access to web servers, to protect server-to-server
communication, and for administrative purposes. In certain
scenarios, authentication of the access device as well as the user is
important. In order to support such scenarios, IP-based systems may
be equipped with device certificates. Several enterprise networks
already have a device authorization infrastructure, enforcing, that
only dedicated devices have access to corporate resources. There can
be benefits in re-using such device certificates in the context of
SIP, e.g., for securing media.
The security provided by device certificates is often is restricted
to the perimeter of the corporate network, as peers outside the
corporate network may not be able to verify a certificate given by a
corporate CA. This also applies to non-corporate environments.
For user-to-user communication, the receiving side needs to be able
to validate a certificate as belonging to the sending side. A device
certificate is not ideally suited to this purpose since it contains a
device specific identifier. Although user certificates would seem to
be a better alternative, there are certain difficulties with this at
present. Users often use different devices at different times, and
to facilitate this (and also prevent unauthorized use of a
certificate in the absence of a user), private keys and certificates
need to be provided to these devices. The dynamic provisioning of
this can be facilitated using smart cards. However, this almost
rules out the simultaneous usage of this card in two devices (e.g.,
hard phone and PC). Moreover, as a complete role out of a PKI,
providing server and user certificates that are globally usable is
not likely in the near future(at least for user certificates),
intermediate steps need to be taken.
This document discusses the usage of certificates with limited
applicability, e.g., device certificates or self-signed certificates
in the context of SIP. In particular, this document focuses on the
session binding of these certificates to user identities.
The scenario, which is the focus of this document, can be described
as follows. Note that the applicability of the approach is not
restricted to this example use case.
A user in a corporate environment has been assigned a hardware-based
phone. With this phone the user may initiate and receive calls
inside the corporate environment and also to/from the outside. Since
the corporate policy requires certain security services to be in
place, e.g., media encryption, for internal as well as external
Fries, et al. Expires June 13, 2007 [Page 3]
Internet-Draft SIP Identity Usage BCP December 2006
calls, the phone needs to support security parameter negotiation
between the participants of a call. To achieve this negotiation
securely, the phone typically needs to be equipped with appropriate
credentials. If in a targeted corporate environment device
certificates are used, they may be reused here as well. Even a self-
signed certificate could be used. The important thing is to be able
to bind a certificate (e.g., device-based or self-signed) to the
identity of the user of the device. Note that since the phone may be
shared by several users, the phone may even be able to generate self-
signed certificates for each user.
Using the phone, i.e., the voice service, requires the user to
authenticate himself, most often based on a username and a password.
One reason why it is assumed that the user does not authenticate
using a certificate and corresponding private key is the lack of an
appropriate interface in order to accomplish the necessary
certificate provision to the phone (e.g., using smart cards or secure
USB tokens). Another appraoch is a central credential server that
distributes the credentials as described in Appendix A.1. Even with
such an interface, the enterprise may not be able to issue globally
resolvable certificates due to technical or financial reasons. So
again, a means to bind the certificate to the identity of the user
would be beneficial.
A certificate available on an IP based phone can be used to secure
the exchange of security parameters. The problem to be solved here
is the binding of available certificate material to a user identity
for the duration of the session.
Fries, et al. Expires June 13, 2007 [Page 4]
Internet-Draft SIP Identity Usage BCP December 2006
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 RFC 2119 [RFC2119].
Fries, et al. Expires June 13, 2007 [Page 5]
Internet-Draft SIP Identity Usage BCP December 2006
3. Existing Building Blocks
RFC 3261 [RFC3261] already describes the transport of certificates
within the SDP body of a message using the S/MIME Key Exchange
approach described in Section 23.2 of [RFC3261]. Here, a user may
submit a self-signed certificate. It is even allowed that the
subjectname field be different from the AoR submitted in the FROM
header field. The drawback is that the receiver may not be able to
verify the validity of the embedded key and associate it with a
particular user identity. This may be the case when the certificate
is a device based certificate, i.e., reflecting the device identity
and not necessarily the identity of the acting user. Another example
is self-signed certificates, which may not be directly connectable to
the user.
[RFC4474] introduces a new entity, called the authentication service,
which provides assurance about the identity in the FROM header field
of a SIP request (such as an INVITE request). The authentication
service does this by adding an assertion to the SIP header of a SIP
request. This assertion provides integrity protection for certain
header fields and also for the body of the SIP request. The
assertion is added after authenticating (and authorizing) the request
initiator, e.g., by HTTP digest authentication.
Fries, et al. Expires June 13, 2007 [Page 6]
Internet-Draft SIP Identity Usage BCP December 2006
4. Scenario and Profile
This document describes a procedure for providing an implicit binding
of a user identity to a certificate available in the body of a
request for the duration of a session. or parameters are defined.
Instead, the procedure uses existing options from RFC 3261 and RFC
4474 to achieve the binding.
Devices may already possess certificates or may generate self-signed
certificates on logon of a new user or on request. A UA may want to
bind these credentials to the identity of the registering user for
the duration of the registration or just for the duration of a
session.
In the following subsections the forward and also the reverse
direction for message exchange is considered. Note that forward
denotes the direction from the caller to the callee, while reverse
relates to the opposite direction. In both directions the recently
published RFC4474 [RFC4474], describing a SIP Authentication Service,
is applied for request messages.
Note that the authentication service may not be held responsible for
attacks on the path between the UAC and the authentication server via
the SIP proxy. As this approach is provided in-band it only requires
an [RFC4474] compliant authentication service to be in place as
additional component.
An extension, allowing the authentication service to add a
fingerprint of a certificate used during the user authentication is
described in Appendix A of this document.
4.1. Forward Credential Processing
When the UA issues a SIP request, the outbound proxy / registrar will
authenticate the UA as having the credentials associated with the
user identified in the FROM header field. For example, the UA may be
challenged to provide HTTP digest authentication. Alternatively, if
the request is received over a TLS connection on which the UA has
been authenticated previously, then further authentication may not be
necessary. Having authenticated the UA, any certificate conveyed in
that request can be implicitly associated with that UA and hence with
the authenticated user, provided the request has been integrity
protected (e.g., through the use of TLS). An authentication service,
as defined in [RFC4474], can then verify that the URI in the FROM
header field corresponds to an AoR that the authenticated user is
allowed to use, and on this basis can provide an assertion in the
forwarded request that the FROM header field URI does indeed identify
the origin of the request. This assertion is in the form of an
Fries, et al. Expires June 13, 2007 [Page 7]
Internet-Draft SIP Identity Usage BCP December 2006
inserted Identity header field in the request (e.g., INVITE) message,
providing a signature over some of the header fields in the forwarded
request and over the entire body, using the domain's private key.
The signature of the authentication service enables the receiving UAC
to verify that the body and thus the certificate has not been
tampered with while in transit from the authentication server to the
recipient, and that it was provided by a particular entity stated in
the FROM field (as indicated in the assertion). The message
integrity together with the assertion create a temporary binding
(identity, certificate) at the receiver side. This can be
facilitated as the authentication service uses a certificate signed
by a well know CA and thus can be verified.
This is important, as the receiving client may not be able to verify
the certificate provided by the initiator of the communication (for
example, it is a self-signed certificate or the certificate was
created by a corporate CA and the root certificate of the issuing CA
cannot be validated). In-band certificate provision may be done as
described in RFC 3261 [RFC3261] for self-signed certificates or by
using the recently proposed new MIKEY option
[I-D.ietf-msec-mikey-rsa-r] for key management, allowing the
certificate transport as part of a MIKEY message, which in turn can
be transmitted in SIP using the [RFC4567] approach.
After verifying the signature, the receiving client stores the
certificate associated with the identity stated in the FROM header
field for the duration of the session. After the session ends the
receiving UA SHOULD delete the association.
Certificate (credential) provisioning using the SIP Identity approach
may be achieved as shown in the following figure.
UAC Proxy UAS
INVITE+cert INVITE+cert+Identity
--------------------> ------------------------>
180+answer 180+answer
<-------------------- <------------------------
PRACK PRACK
--------------------> ------------------------>
200 (PRACK) 200(PRACK)
<-------------------- <------------------------
In any case, using the approach described in [RFC4474], the
authentication service, through the signature over the body,
Fries, et al. Expires June 13, 2007 [Page 8]
Internet-Draft SIP Identity Usage BCP December 2006
implicitly asserts that the identity in the FROM field is somehow
connected to a certificate in the body.
4.2. Reverse Credential Processing
Response identity, e.g., for the mutual exchange of certificates,
cannot be achieved using the approach described in [RFC4474]. Here,
a the recently submitted ID handling connected SIP identity
[I-D.ietf-sip-connected-identity] provides a solution. This ID
describes an approach for targeting the authenticated connected
identity provisioning using [RFC4474]. This approach can be
leveraged to provide the credentials of the callee to the caller in a
similar way as described in Section 4.1.
Certificate (credential) provisioning using the connected identity
approach may be achieved as shown in the following figure.
UAC Proxy UAS
INVITE+cert INVITE+cert+Identity
--------------------> ------------------------>
180+answer 180+answer
<-------------------- <------------------------
PRACK PRACK
--------------------> ------------------------>
200 (PRACK) 200(PRACK)
<-------------------- <------------------------
UPDATE+cert+Identity UPDATE+cert
<-------------------- <------------------------
200 (UPDATE) 200 (UPDATE)
--------------------> ------------------------>
The offer is sent in the INVITE request and the answer is sent in a
reliable response. However, the response, which may transport a
certificate, cannot be signed with an Identity header field according
to [RFC4474]. Consequently, the certificate has to be provided using
a request in the reverse direction, in the figure above an UPDATE
request, which is sent via the authentication service. Here, as in
the forward direction, certain header fields and the body of the
message of the request will be signed. The signature is provided
using the Identity header field, which can then be used on the caller
side as the credential to be used for the callee.
For the steps how the received credential is handled, we refer to
Fries, et al. Expires June 13, 2007 [Page 9]
Internet-Draft SIP Identity Usage BCP December 2006
Section 4.1.
4.3. Usage Example
In the following an example is given to depict the usage of this BCP
in a common scenario. Let's assume we have the standard SIP
trapezoid as scenario were SIP UA Alice is connected to the SIP Proxy
located in domain example.com. Alice want's to call Bob residing in
the (different administrative) domain biloxli.com as shown below.
atlanta.com . . . biloxi.com
. proxy proxy .
. .
Alice's . . . . . . . . . . . . . . . . . . . . Bob's
Alice and Bob both support the MIKEY-RSA-R approach (ref.
[I-D.ietf-msec-mikey-rsa-r]) for setting up keys for securing the
media exchange. Here, the sender and receiver do not need to know
the certificate of the other peer in advance as it can be sent in the
MIKEY initiator message. Thus, the receiver of this message can
utilize the received key material to encrypt the session parameter
and send them back as part of the MIKEY response message. The
certificate check of the embedded certificate may be done depending
on the signing authority. The call flow can be described as
following:
UA1 Proxy UA2
INVITE+MIKEY-RSA-R-I-Msg. INVITE+MIKEY-RSA-R-I-Msg.+Sig.
-----------------------------> ------------------------------>
180+MIKEY-RSA-R-R-Msg. 180+MIKEY-RSA-R-R-Msg.
<----------------------------- <------------------------------
PRACK PRACK
-----------------------------> ------------------------------>
200 (PRACK) 200(PRACK)
<----------------------------- <------------------------------
For the sake of simplicity only the successful forward case is shown
here. Upon receiving the INVITE message, UA2 checks the Identity
Info header and verifies the signature according to [RFC4474]. After
successful verification UA2 stores the certificate, which is part of
the MIKEY _RSA_R Initiator message with the identity stated in the
FROM header field. This certificate is used in the response to the
request to secure the MIKEY-RSA-R answer. UA2 stores the certificate
for the duration of the session. Besides use for securing the inital
MIKEY exchange, the certificate may be used to secure further
Fries, et al. Expires June 13, 2007 [Page 10]
Internet-Draft SIP Identity Usage BCP December 2006
security messages, like re-keying or similar. Note, that the usage
of MIKEY is stated here only as an example. The BCP is not bound to
MIKEY but is applicable to any kind of certificate transmission.
Fries, et al. Expires June 13, 2007 [Page 11]
Internet-Draft SIP Identity Usage BCP December 2006
5. Conclusion
In this document we present a procedure for in-band certificate
exchange and association with an identity in the FROM header field as
a best current practice use case for [RFC4474]. It would require a
callee UA to store an association of identity and certificate for the
duration of a session. This is done in order for the receiver to
ensure that during the entire session the same certificate/private
key is used for cryptographic purposes with the calling UA. This
creates a temporary binding (identity, certificate) at the callee
side. Similarly a request may be sent in the reverse direction via
an authentication service containing the certificate of the callee,
creating a temporary binding at the caller side.
Alternative approaches are described in Appendix A. These
alternatives, however, suffer from some limitations or require
protocol extensions.
Fries, et al. Expires June 13, 2007 [Page 12]
Internet-Draft SIP Identity Usage BCP December 2006
6. Security Considerations
To avoid the use of a dedicated certificate and private key pair from
several users, the device needs to ensure that a fresh key pair is
generated upon user login. Here it is assumed that the device does
not provide an appropriate interface for the credential provisioning.
The lifetime of the certificate may be rather short. A new
certificate may be generated during the period of registration if a
certificate expires.
If a certificate is compromised, it needs to be revoked and a new
certificate has to be issued to the device. Following the approach
in [I-D.ietf-sip-certs] a notification with an empty body may be sent
to indicate that the certificate is no longer valid. Alternatively
out-of-band mechanisms can be used. If certificate revocation is
necessary may depend on the lifetime of the certificates.
If signaling security in terms of TLS is not provided on the path to
the authentication proxy, an adversary may copy and paste the
credential material included in the original request message into
another request, which may lead to wrong bindings at the receiver
side. Note, that the adversary does not have the corresponding
private key, thus is not able to establish a security association
with the receiver.
Fries, et al. Expires June 13, 2007 [Page 13]
Internet-Draft SIP Identity Usage BCP December 2006
7. IANA Considerations
This document does not require actions by IANA.
Fries, et al. Expires June 13, 2007 [Page 14]
Internet-Draft SIP Identity Usage BCP December 2006
8. Acknowledgments
The authors would like to thank Jon Peterson and Cullen Jennings as
well as Francois Audet for the discussions in context of SIP
identity. Especially the authors would also like to thank John
Elwell for the discussion in the context of connected identity.
Additionally, we would like to thank Andreas Pashalidis for his
comments.
Fries, et al. Expires June 13, 2007 [Page 15]
Internet-Draft SIP Identity Usage BCP December 2006
9. References
9.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.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
9.2. Informative References
[I-D.ietf-msec-mikey-rsa-r]
Ignjatic, D., "An additional mode of key distribution in
MIKEY: MIKEY-RSA-R", draft-ietf-msec-mikey-rsa-r-07 (work
in progress), August 2006.
[I-D.ietf-sip-certs]
Jennings, C., "Certificate Management Service for The
Session Initiation Protocol (SIP)",
draft-ietf-sip-certs-02 (work in progress), October 2006.
[I-D.ietf-sip-connected-identity]
Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", draft-ietf-sip-connected-identity-02
(work in progress), October 2006.
[I-D.ietf-sip-saml]
Tschofenig, H., "SIP SAML Profile and Binding",
draft-ietf-sip-saml-01 (work in progress), October 2006.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E.
Carrara, "Key Management Extensions for Session
Description Protocol (SDP) and Real Time Streaming
Protocol (RTSP)", RFC 4567, July 2006.
Fries, et al. Expires June 13, 2007 [Page 16]
Internet-Draft SIP Identity Usage BCP December 2006
Appendix A. Alternative Approaches
A.1. Associating user identity and credentials upfront
SIP-CERTS [I-D.ietf-sip-certs] and SIP Identity [RFC4474] are two
promising approaches that help to deal with the problem that
deployment of end user certificates and a global PK infrastructure is
not available.
[I-D.ietf-sip-certs] is suitable to provide certificate information
to the end hosts and end users via a credential server. UAs can
fetch certificates and use them as necessary. UAs may also store
their own credentials on the credential server. This may be done
also (only) for the duration of a registration, which enables other
UAs to fetch the certificate upfront, before starting communication
with the target UA. This approach requires that both parties have
sufficient access to a credential server. Besides the credential
server, also an authentication server may be needed to support
certain scenarios.
This approach works nicely in many environments but there may be
limitations in others.
In order to use the credential server in a way in which certificates
are globally accessible it is necessary to put the credential server
on the public Internet. This is in order to enable users to access
the certificate information before making or answering a call. This
approach may not be feasible for all enterprises, as there are
certain company based regulations regarding the safeguarding of
employee information. A corporate directory for instance is normally
not accessible by people outside the enterprise.
The combination of both concepts, namely SIP Identity and SIP-CERTS,
provides the possibility to route a NOTIFY, which contains a
certificate from the credential server, via the authentication
service to the UA. As stated in [I-D.ietf-sip-certs], if the
identity asserted by the authentication service matches the AOR that
the UA subscribed to, the certificate in the NOTIFY can be treated as
valid and may be used for the protection of subsequent communication.
A general precondition is that the UA and the authentication server
trust the same root CA.
This latter approach requires the certificate SubjectAltName to match
a given AoR, as described in Section 8.10 of [I-D.ietf-sip-certs],
thus leaving certain device certificates or certain self-signed
certificates outside the possible solution.
Fries, et al. Expires June 13, 2007 [Page 17]
Internet-Draft SIP Identity Usage BCP December 2006
A.2. Enhancements to SIP Identity using SIP SAML
As required by [RFC4474], the authentication server has to
authenticate the user whose identity appears in the FROM field of the
SIP request by some means, e.g., by challenging the user.
Additionally, an authentication server may also check and assert,
that a dedicated certificate was used during registration over a TLS
protected link for the authentication on the TLS level. This
approach is currently not be possible with [RFC4474] and would
require further specification.
A document supporting this approach is provided in SIP-SAML
[I-D.ietf-sip-saml], which enables SAML assertions and artifacts to
be carried in SIP. This document offers a mechanism to deliver
additional information about previously executed authentication
towards a registrar .
Fries, et al. Expires June 13, 2007 [Page 18]
Internet-Draft SIP Identity Usage BCP December 2006
Authors' Addresses
Steffen Fries
Siemens AG
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: steffen.fries@siemens.com
Hannes Tschofenig
Siemens Networks GmbH & Co KG
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
Kai Fischer
Siemens Enterprise Communications GmbH & Co KG
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Kai.Fischer@siemens.com
Fries, et al. Expires June 13, 2007 [Page 19]
Internet-Draft SIP Identity Usage BCP December 2006
Full Copyright Statement
Copyright (C) The IETF Trust (2006).
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).
Fries, et al. Expires June 13, 2007 [Page 20]