One document matched: draft-ietf-sip-certs-14.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc category="std" docName="draft-ietf-sip-certs-14" ipr="pre5378Trust200902">
<front>
<title abbrev="SIP Certificates">Certificate Management Service for The
Session Initiation Protocol (SIP)</title>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 421-9990</phone>
<email>fluffy@cisco.com</email>
</address>
</author>
<author fullname="Jason Fischl" initials="J." role="editor"
surname="Fischl">
<organization>Skype</organization>
<address>
<postal>
<street>2145 Hamilton Ave.</street>
<city>San Jose</city>
<region>CA</region>
<code>95125</code>
<country>USA</country>
</postal>
<phone>+1-415-202-5192</phone>
<email>jason.fischl@skype.net</email>
</address>
</author>
<date day="30" month="June" year="2010" />
<abstract>
<t>This draft defines a Credential Service that allows Session
Initiation Protocol (SIP) User Agents (UAs) to use a SIP event package
to discover the certificates of other users. This mechanism allows user
agents that want to contact a given Address-of-Record (AOR) to retrieve
that AOR's certificate by subscribing to the Credential Service, which
returns an authenticated response containing that certificate. The
Credential Service also allows users to store and retrieve their own
certificates and private keys.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="RFC3261"></xref>, as amended by <xref
target="RFC3853"></xref>, provides a mechanism for end-to-end encryption
and integrity using <xref target="RFC3851">S/MIME</xref>. Several
security properties of <xref target="RFC3261"></xref> depend on S/MIME,
and yet it has not been widely deployed. One reason is the complexity of
providing a reasonable certificate distribution infrastructure. This
specification proposes a way to address discovery, retrieval, and
management of certificates for SIP deployments. Combined with the <xref
target="RFC4474">SIP Identity </xref> specification, this specification
allows users to have certificates that are not signed by any well known
certification authority while still strongly binding the user's identity
to the certificate.</t>
<t>In addition, this specification provides a mechanism that allows SIP
User Agents such as IP phones to enroll and get their credentials
without any more configuration information than they commonly have
today. The end user expends no extra effort.</t>
</section>
<section title="Definitions">
<t>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 <xref
target="RFC2119"></xref>.</t>
<t><list style="hanging">
<t hangText="Certificate:">A <xref target="RFC5280">PKIX</xref>
style certificate containing a public key and a list of identities
in the SubjectAltName that are bound to this key. The certificates
discussed in this draft are generally self-signed and use the
mechanisms in the <xref target="RFC4474">SIP Identity</xref>
specification to vouch for their validity. Certificates that are
signed by a certification authority can also be used with all the
mechanisms in this draft, however, they need not be validated by the
receiver (although the receiver can validate them for extra
assurance; see <xref target="cert.extra"></xref>).</t>
<t hangText="Credential:">For this document, credential means the
combination of a certificate and the associated private key.</t>
<t hangText="Password Phrase:">A password used to encrypt and
decrypt a PKCS#8 private key.</t>
</list></t>
</section>
<section title="Overview">
<t>The general approach is to provide a new SIP service referred to as a
"credential service" that allows SIP User Agents (UAs) to subscribe to
other users' certificates using a new <xref target="RFC3265">SIP event
package</xref>. The certificate is delivered to the subscribing UA in a
corresponding SIP NOTIFY request. An Authentication Service as described
in the <xref target="RFC4474"> SIP Identity </xref> specification can be
used to vouch for the identity of the sender of the certificate by using
the sender's proxy domain certificate to sign the NOTIFY request. The
Authentication Service is vouching that the sender is allowed to
populate the SIP From header field value. The sender of the message is
vouching that this is an appropriate certificate for the user identified
in the SIP from header field value. The credential service can manage
public certificates as well as the user's private keys. Users can update
their credentials, as stored on the credential service, using a SIP
<xref target="RFC3903">PUBLISH</xref> request. The UA authenticates to
the credential service using a shared secret when a UA is updating a
credential. Typically the shared secret will be the same one that is
used by the UA to authenticate a REGISTER request with the Registrar for
the domain (usually with SIP Digest Authentication).</t>
<t>The following figure shows Bob publishing his credentials from one of
his User Agents (e.g. his laptop software client), retrieving his
credentials from another of his User Agents (e.g. his mobile phone), and
then Alice retrieving Bob's certificate and sending a message to Bob.
SIP 200-class responses are omitted from the diagram to make the figure
easier to understand.</t>
<figure>
<artwork><![CDATA[
example.com domain
------------------
Alice Proxy Auth Cred Bob1 Bob2
| | | | TLS Handshake | |
| [ Bob generates ] |<--------------------->|
| [ credentials and ] | PUBLISH (credential) |
| [ publishes them ] |<----------------------|
| | | | Digest Challenge |
| | | |---------------------->|
| | | | PUBLISH + Digest |
| | | |<----------------------|
| | | | |
| | | | time passes... |
| | | | |
| | | | TLS Handshake |
| [ Bob later gets ] |<---------------->|
| [ back his own ] | SUBSCRIBE |
| [ credentials ] | (credential) |
| [ at another ] |<-----------------|
| [ User Agent ] | SUBSCRIBE+Digest |
| | | |<-----------------|
| | | | NOTIFY |
| | | |----------------->|
| | | | Bob Decrypts key |
| | | | |
| | | | |
| SUBSCRIBE (certificate) | Alice fetches |
|---------->|----->|----->| Bob's cert |
| | |NOTIFY| |
| NOTIFY+Identity |<-----| |
|<----------+------| | Alice uses cert |
| | | | to encrypt |
| MESSAGE | | | message to Bob |
|---------->|------+------+----------------->|
]]></artwork>
</figure>
<t>Bob's UA (Bob2) does a <xref target="RFC5246">TLS</xref> handshake
with the credential server to authenticate that the UA is connected to
the correct credential server. Then Bob's UA publishes his newly created
or updated credentials. The credential server digest challenges the UA
to authenticate that the UA knows Bob's shared secret. Once the UA is
authenticated, the credential server stores Bob's credentials.</t>
<t>Another of Bob's User Agents (Bob1) wants to fetch its current
credentials. It does a <xref target="RFC5246">TLS</xref> handshake with
the credential server to authenticate that the UA is connected to the
correct credential server. Then Bob's UA subscribes for the credentials.
The credential server digest challenges the UA to authenticate that the
UA knows Bob's shared secret. Once the UA is authenticated, the
credential server sends a NOTIFY that contains Bob's credentials. The
private key portion of the credential may have been encrypted with a
secret that only Bob's UA (and not the credential server) knows. In this
case, once Bob's UA decrypts the private key it will be ready to go.
Typically Bob's UA would do this when it first registered on the
network.</t>
<t>Some time later Alice decides that she wishes to discover Bob's
certificate so that she can send him an encrypted message or so that she
can verify the signature on a message from Bob. Alice's UA sends a
SUBSCRIBE message to Bob's AOR. The proxy in Bob's domain routes this to
the credential server via an "authentication service" as defined in
<xref target="RFC4474"></xref>. The credential server returns a NOTIFY
that contains Bob's public certificate in the body. This is routed
through an authentication service that signs that this message really
can validly claim to be from the AOR "sip:bob@example.com". Alice's UA
receives the certificate and can use it to encrypt a message to Bob.</t>
<t>It is critical to understand that the only way that Alice can trust
that the certificate really is the one for Bob and that the NOTIFY has
not been spoofed is for Alice to check that the <xref target="RFC4474">
Identity </xref> header field value is correct.</t>
<t>The mechanism described in this document works for both self-signed
certificates and certificates signed by well known certification
authorities. In order to deploy certificates signed by well known
certification authorities, certification authorities would have to
support adding SIP URIs to the SubjectAltName of the certificates they
generate. This is something which has been rarely implemented by
commercial certification authorities. However, most UAs would only use
self-signed certificates and would use an Authentication Service as
described in <xref target="RFC4474"></xref> to provide a strong binding
of an AOR to the certificates.</t>
<t>The mechanisms described in this draft allow for three different
styles of deployment:</t>
<t><list style="numbers">
<t>Deployments where the credential server only stores certificates
and does not store any private key information. If the deployment
had users with multiple devices, some other scheme (perhaps even
manual provisioning) would be used to get the right private keys
onto all the devices that a user uses.</t>
<t>Deployments where the credential server stores certificates and
also stores an encrypted version of the private keys. The credential
server would not know or need the password phrase for decrypting the
private key. The credential server would help move the private keys
between devices but the user would need to enter a password phrase
on each device to allow that device to decrypt (and encrypt) the
private key information.</t>
<t>Deployments where the credential server generates and stores the
certificates and private keys. Deployments such as these may not use
password phrases. Consequently, the private keys are not encrypted
inside the PKCS#8 objects. This style of deployment would often have
the credential server, instead of the devices, create the
credentials.</t>
</list></t>
</section>
<section title="UA Behavior with Certificates">
<t>When a User Agent wishes to discover some other user's certificate it
subscribes to the "certificate" SIP event package as described in <xref
target="certificate"></xref> to get the certificate. While the
subscription is active, if the certificate is updated, the Subscriber
will receive the updated certificate in a notification.</t>
<t>The Subscriber needs to decide how long it is willing to trust that
the certificate it receives is still valid. If the certificate is
revoked before it expires, the Notifier will send a notification with an
empty body to indicate that the certificate is no longer valid. If the
certificate is renewed before it expires, the Notifier will send a
notification with a body containing the new certificate. Note that the
Subscriber might not receive the notification if an attacker blocks this
traffic. The amount of time that the Subscriber caches a certificate
SHOULD be configurable. A default of one day is RECOMMENDED.</t>
<t>Note that the actual duration of the subscription is unrelated to the
caching time or validity time of the corresponding certificate. Allowing
subscriptions to persist after a certificate is no longer valid ensures
that Subscribers receive the replacement certificate in a timely
fashion. The Notifier could return an immediate notification with the
certificate in response to subscribe and then immediately terminate
subscription, setting the reason parameter to "probation". The
Subscriber will have to periodically poll the Notifier to verify
validity of the certificate.</t>
<t>If the UA uses a cached certificate in a request and receives a 437
(Unsupported Certificate) response, it SHOULD remove the certificate it
used from the cache, attempt to fetch the certificate again. If the
certificate is changed, then the UA SHOULD retry the original request
again with the new certificate. This situation usually indicates that
the certificate was recently updated, and that the Subscriber has not
received a corresponding notification. If the certificate fetched is the
same as the one that was previously in the cache, then the UA SHOULD NOT
try the request again. This situation can happened when the request was
retargeted to a different user than the original request. The 437
response is defined in <xref target="RFC4474"></xref>.</t>
<t><list>
<t>Note: A UA that has a presence list MAY want to subscribe to the
certificates of all the presentities in the list when the UA
subscribes to their presence, so that when the user wishes to
contact a presentity, the UA will already have the appropriate
certificate. Future specifications might consider the possibility of
retrieving the certificates along with the presence documents.</t>
</list></t>
<t>The details of how a UA deals with receiving encrypted messages is
outside the scope of this specification. It is worth noting that if
Charlie's UAS receives a request that is encrypted to Bob, it would be
valid and legal for that UA to send a 302 redirecting the call to
Bob.</t>
</section>
<section anchor="ua.cred" title="UA Behavior with Credentials">
<t>UAs discover their own credentials by subscribing to their AOR with
an event type of credential as described in <xref
target="credential"></xref>. After a UA registers, it SHOULD retrieve
its credentials by subscribing to them as described in <xref
target="gen.sub"></xref>.</t>
<t>When a UA discovers its credential, the private key information might
be encrypted with a password phrase. The UA SHOULD request that the user
enter the password phrase on the device, and the UA MAY cache this
password phrase for future use.</t>
<t>There are several different cases in which a UA should generate a new
credential: <list style="symbols">
<t>If the UA receives a NOTIFY with no body for the credential
package.</t>
<t>If the certificate has expired.</t>
<t>If the certificate's notAfter date is within the next 600
seconds, the UA SHOULD attempt to create replacement credentials.
The UA does this by waiting a random amount of time between 0 and
300 seconds. If no new credentials have been received in that time,
the UA creates new credentials to replace the expiring ones and
sends them in a PUBLISH request following the rules for modifying
event state from Section 4.4 of <xref target="RFC3903"></xref>.</t>
<t>If the user of the device has indicated via the user interface
that they wish to revoke the current certificate and issue a new
one.</t>
</list> Credentials are created by creating a new key pair which will
require appropriate randomness as described in <xref
target="RFC4086"></xref> and then creating a certificate as described in
<xref target="cert.gen"></xref>. The UA MAY encrypt the private key with
a password phrase supplied by the user as specified in <xref
target="sec-pwd"></xref>. Next, the UA updates the user's credential by
sending a <xref target="RFC3903">PUBLISH</xref> request with the
credentials or just the certificate as described in <xref
target="gen.pub"></xref>.</t>
<t>If a UA wishes to revoke the existing certificate without publishing
a new one, it MUST send a PUBLISH with an empty body to the credential
server.</t>
</section>
<section anchor="certificate"
title="Event Package Formal Definition for "certificate"">
<section title="Event Package Name">
<t>This document defines a SIP Event Package as defined in <xref
target="RFC3265"></xref>. The event-package token name for this
package is:</t>
<figure>
<artwork><![CDATA[
certificate
]]></artwork>
</figure>
</section>
<section title="SUBSCRIBE Bodies">
<t>This package does not define any SUBSCRIBE bodies.</t>
</section>
<section title="Subscription Duration">
<t>Subscriptions to this event package can range from no time to
weeks. Subscriptions in days are more typical and are RECOMMENDED. The
default subscription duration for this event package is one day.</t>
<t>The credential service is encouraged to keep the subscriptions
active for AORs that are communicating frequently, but the credential
service MAY terminate the subscription at any point in time.</t>
</section>
<section title="NOTIFY Bodies">
<t>The body of a NOTIFY request for this package MUST either be empty
or contain an application/pkix-cert body (as defined in <xref
target="RFC2585"></xref>) that contains the certificate, unless an
Accept header field has negotiated some other type. The
Content-Disposition MUST be set to "signal" as defined in <xref
target="RFC3204"></xref>.</t>
<t>A future extension MAY define other NOTIFY bodies. If no "Accept"
header field is present in the SUBSCRIBE, the body type defined in
this document MUST be assumed.</t>
<t>Implementations which generate large notifications are reminded to
follow the message size restrictions for unreliable transports
articulated in Section 18.1.1 of SIP.</t>
</section>
<section anchor="gen.sub"
title="Subscriber Generation of SUBSCRIBE Requests">
<t>A UA discovers a certificate by sending a SUBSCRIBE request with an
event type of "certificate" to the AOR for which a certificate is
desired. In general, the UA stays subscribed to the certificate for as
long as it plans to use and cache the certificate, so that the UA can
be notified about changes or revocations to the certificate.</t>
<t>Subscriber User Agents will typically subscribe to certificate
information for a period of hours or days, and automatically attempt
to re-subscribe just before the subscription is completely
expired.</t>
<t>When a user de-registers from a device (logoff, power down of a
mobile device, etc.), subscribers SHOULD unsubscribe by sending a
SUBSCRIBE request with an Expires header field of zero.</t>
</section>
<section title="Notifier Processing of SUBSCRIBE Requests">
<t>When a SIP credential server receives a SUBSCRIBE request with the
certificate event-type, it is not necessary to authenticate the
subscription request. The Notifier MAY limit the duration of the
subscription to an administrator-defined period of time. The duration
of the subscription does not correspond in any way to the period for
which the certificate will be valid.</t>
<t>When the credential server receives a SUBSCRIBE request for a
certificate, it first checks to see if it has credentials for the
requested URI. If it does not have a certificate, it returns a NOTIFY
request with an empty message body.</t>
</section>
<section title="Notifier Generation of NOTIFY Requests">
<t>Immediately after a subscription is accepted, the Notifier MUST
send a NOTIFY with the current certificate, or an empty body if no
certificate is available for the target user. In either case it forms
a NOTIFY with the From header field value set to the value of the To
header field in the SUBSCRIBE request. This server sending the NOTIFY
needs either to implement an Authentication Service (as described in
<xref target="RFC4474">SIP Identity </xref>) or else the server needs
to be set up such that the NOTIFY request will be sent through an
Authentication Service. Sending the NOTIFY request through the
Authentication Service requires the SUBSCRIBE request to have been
routed through the Authentication Service, since the NOTIFY is sent
within the dialog formed by the subscription.</t>
</section>
<section title="Subscriber Processing of NOTIFY Requests">
<t>The resulting NOTIFY will contain an application/pkix-cert body
that contains the requested certificate. The UA MUST follow the
procedures in <xref target="trust"></xref> to decide if the received
certificate can be used. The UA needs to cache this certificate for
future use. The maximum length of time it should be cached for is
discussed in <xref target="section.revocation"></xref>. The
certificate MUST be removed from the cache if the certificate has been
revoked (if a NOTIFY with an empty body is received), or if it is
updated by a subsequent NOTIFY. The UA MUST check that the NOTIFY is
correctly signed by an Authentication Service as described in <xref
target="RFC4474"></xref>. If the identity asserted by the
Authentication Service does not match the AOR that the UA subscribed
to, the certificate in the NOTIFY is discarded and MUST NOT be
used.</t>
</section>
<section title="Handling of Forked Requests">
<t>This event package does not permit forked requests. At most one
subscription to this event type is permitted per resource.</t>
</section>
<section title="Rate of Notifications">
<t>Notifiers SHOULD NOT generate NOTIFY requests more frequently than
once per minute.</t>
</section>
<section title="State Agents and Lists">
<t>The credential server described in this section which serves
certificates is a state agent as defined in <xref
target="RFC3265"></xref> and implementations of the credential server
MUST be implemented as a state agent.</t>
<t>Implementers MUST NOT use the <xref target="RFC4662">event list
extension</xref> with this event type. It is not possible to make such
an approach work, because the Authentication service would have to
simultaneously assert several different identities.</t>
</section>
<section anchor="proxy" title="Behavior of a Proxy Server">
<t>There are no additional requirements on a SIP Proxy, other than to
transparently forward the SUBSCRIBE and NOTIFY requests as required in
SIP. This specification describes the Proxy, Authentication service,
and credential service as three separate services, but it is certainly
possible to build a single SIP network element that performs all of
these services at the same time.</t>
</section>
</section>
<section anchor="credential"
title="Event Package Formal Definition for "credential" ">
<section title="Event Package Name">
<t>This document defines a SIP Event Package as defined in <xref
target="RFC3265"></xref>. The event-package token name for this
package is:</t>
<figure>
<artwork><![CDATA[
credential
]]></artwork>
</figure>
</section>
<section title="SUBSCRIBE Bodies">
<t>This package does not define any SUBSCRIBE bodies.</t>
</section>
<section title="Subscription Duration">
<t>Subscriptions to this event package can range from hours to one
week. Subscriptions in days are more typical and are RECOMMENDED. The
default subscription duration for this event package is one day.</t>
<t>The credential service SHOULD keep subscriptions active for UAs
that are currently registered.</t>
</section>
<section title="NOTIFY Bodies">
<t>An implementation compliant to this specification MUST support the
multipart/mixed type (see <xref target="RFC2046"></xref>). This allows
a notification to contain multiple resource documents including at a
minimum the application/pkix-cert body with the certificate and an
application/pkcs8 body that has the associated private key information
for the certificate. The application/pkcs8 media type is defined in
<xref target="I-D.turner-asymmetrickeyformat"></xref>.</t>
<t>The absence of an Accept header in the SUBSCRIBE indicates support
for multipart/mixed and the content types application/pkix-cert and
application/pkcs8. If an Accept header is present, these types MUST be
included, in additional to any other types supported by the
client.</t>
<t>The application/pkix-cert body is a DER encoded X.509v3 certificate
<xref target="RFC2585"></xref>. The application/pkcs8 body contains a
DER-encoded <xref target="I-D.turner-asymmetrickeyformat"></xref>
object that contains the private key. The PKCS#8 objects MUST be of
type PrivateKeyInfo. The integrity and confidentiality of the PKCS#8
objects is provided by the TLS transport. The transport encoding of
all the MIME bodies is binary.</t>
</section>
<section anchor="subscriber.behavior"
title="Subscriber Generation of SUBSCRIBE Requests">
<t>A Subscriber User Agent will subscribe to its credential
information for a period of hours or days and will automatically
attempt to re-subscribe before the subscription has completely
expired.</t>
<t>The Subscriber SHOULD subscribe to its credentials whenever a new
user becomes associated with the device (a new login). The subscriber
SHOULD also renew its subscription immediately after a reboot, or when
the subscriber's network connectivity has just been
re-established.</t>
<t>The UA needs to authenticate with the credential service for these
operations. The UA MUST use TLS to directly connect to the server
acting as the credential service or to a server that is authoritative
for the domain of the credential service. The UA MUST NOT connect
through an intermediate proxy to the credential service. The UA may be
configured with a specific name for the credential service; otherwise
normal SIP routing is used. As described in RFC 3261, the TLS
connection needs to present a certificate that matches the expected
name of the server to which the connection was formed, so that the UA
knows it is talking to the correct server. Failing to do this may
result in the UA publishing its private key information to an
attacker. The credential service will authenticate the UA using the
usual SIP Digest mechanism, so the UA can expect to receive a SIP
challenge to the SUBSCRIBE or PUBLISH requests.</t>
</section>
<section anchor="notifier.subscribe.behavior"
title="Notifier Processing of SUBSCRIBE Requests">
<t>When a credential service receives a SUBSCRIBE for a credential,
the credential service has to authenticate and authorize the UA and
validate that adequate transport security is being used. Only a UA
that can authenticate as being able to register as the AOR is
authorized to receive the credentials for that AOR. The Credential
Service MUST digest challenge the UA to authenticate the UA and then
decide if it is authorized to receive the credentials. If
authentication is successful, the Notifier MAY limit the duration of
the subscription to an administrator-defined period of time. The
duration of the subscription MUST NOT be larger than the length of
time for which the certificate is still valid. The Expires header
field SHOULD be set so that it is not longer than the notAfter date in
the certificate.</t>
</section>
<section title="Notifier Generation of NOTIFY Requests">
<t>Once the UA has authenticated with the credential service and the
subscription is accepted, the credential service MUST immediately send
a Notify request. The Authentication Service is applied to this NOTIFY
request in the same way as the certificate subscriptions. If the
credential is revoked, the credential service MUST terminate any
current subscriptions and force the UA to re-authenticate by sending a
NOTIFY with its Subscription-State header field set to "terminated"
and a reason parameter of "deactivated". (This causes a Subscriber to
retry the subscription immediately.) This is so that if a secret for
retrieving the credentials gets compromised, the rogue UA will not
continue to receive credentials after the compromised secret has been
changed.</t>
<t>Any time the credentials for this URI change, the credential
service MUST send a new NOTIFY to any active subscriptions with the
new credentials.</t>
<t>The notification MUST be sent over TLS so that it is integrity
protected and the TLS needs to be directly connected between the UA
and the credential service with no intermediaries.</t>
<t></t>
</section>
<section anchor="gen.pub" title="Generation of PUBLISH Requests">
<t>A user agent SHOULD be configurable to control whether it publishes
the credential for a user or just the user's certificate.</t>
<t>When publishing just a certificate, the body contains an
application/pkix-cert. When publishing a credential, the body contains
a multipart/mixed containing both an application/pkix-cert and an
application/pkcs8 body.</t>
<t>When the UA sends the <xref target="RFC3903">PUBLISH</xref>
request, it needs to do the following: <list style="symbols">
<t>The UA MUST use TLS to directly connect to the server acting as
the credential service or to a server that is authoritative for
the domain of the credential service. The UA MUST NOT connect
through an intermediate proxy to the credential service.</t>
<t>The Expires header field value in the PUBLISH request SHOULD be
set to match the time for which the certificate is valid.</t>
<t>If the certificate includes Basic Constraints, it SHOULD set
the cA flag to false.</t>
</list></t>
</section>
<section anchor="notifier.publish.behavior"
title="Notifier Processing of PUBLISH Requests">
<t>When the credential service receives a PUBLISH to update
credentials, it MUST authenticate and authorize this request the same
way as for subscriptions for credentials. If the authorization
succeeds, then the credential service MUST perform the following check
on the certificate: <list style="symbols">
<!--
<t>One of the names in the SubjectAltName of the certificate
matches the authorized user making the request.</t>
-->
<t>The notBefore validity time MUST NOT be in the future.</t>
<t>The notAfter validity time MUST be in the future.</t>
<t>If a cA Basic Constraint flag is set in the certificate, it is
set to false.</t>
</list> If all of these succeed, the credential service updates the
credential for this URI, processes all the active certificates and
credential subscriptions to this URI, and generates a NOTIFY request
with the new credential or certificate. Note the SubjectAltName SHOULD
NOT be checked as that would restrict which certificates could be used
and offers no additional security guarantees.</t>
<t>If the Subscriber submits a PUBLISH request with no body and
Expires=0, this revokes the current credentials. Watchers of these
credentials will receive update with no body indicating that they MUST
stop any previously stored credentials. Note that subscriptions to the
certificate package are NOT terminated; each subscriber to the
certificate package receives a notification with an empty body.</t>
</section>
<section title="Subscriber Processing of NOTIFY Requests">
<t>When the UA receives a valid NOTIFY request, it should replace its
existing credentials with the new received ones. If the UA cannot
decrypt the PKCS#8 object, it MUST send a 437 (Unsupported
Certificate) response. Later if the user provides a new password
phrase for the private key, the UA can subscribe to the credentials
again and attempt to decrypt with the new password phrase.</t>
</section>
<section title="Handling of Forked Requests">
<t>This event package does not permit forked requests.</t>
</section>
<section title="Rate of Notifications">
<t>Notifiers SHOULD NOT generate NOTIFY requests more frequently than
once per minute.</t>
</section>
<section title="State Agents and Lists">
<t>The credential server described in this section which serves
credentials is a state agent and implementations of the credential
server MUST be implemented as a state agent.</t>
<t>Implementers MUST NOT use the <xref target="RFC4662">event list
extension</xref> with this event type.</t>
</section>
<section title="Behavior of a Proxy Server">
<t>The behavior is identical to behavior described for certificate
subscriptions described in <xref target="proxy"></xref>.</t>
</section>
</section>
<section title="Identity Signatures">
<t>The <xref target="RFC4474"></xref> Authentication service defined an
signature algorithm based on SHA-1 called rsa-sha1. This specification
adds an signature algorithm that is roughly the same but based on
SHA-256 and called rsa-sha256.</t>
<t>When using the rsa-sha256 algorithm, the signature MUST be computed
in exactly the same way as described in section 9 of <xref
target="RFC4474"></xref> with the exception that instead of using
sha1WithRSAEncryption, the computation is done using
sha256WithRSAEncryption as described in <xref
target="RFC5754"></xref>.</t>
<t>Implementations of this specification MUST implement both rsa-sha1
and rsa-sha256. The IANA registration for rsa-sha256 is defined in <xref
target="sec:iana-alg"></xref>.</t>
</section>
<section title="Examples">
<t>In all these examples, large parts of the messages are omitted to
highlight what is relevant to this draft. The lines in the examples that
are prefixed by $ represent encrypted blocks of data.</t>
<section title="Encrypted Page Mode IM Message ">
<t>In this example, Alice sends Bob an encrypted page mode instant
message. Alice does not already have Bob's public key from previous
communications, so she fetches Bob's public key from Bob's credential
service:</t>
<figure>
<artwork><![CDATA[
SUBSCRIBE sip:bob@biloxi.example.com SIP/2.0
...
Event: certificate
]]></artwork>
</figure>
<t>The credential service responds with the certificate in a
NOTIFY.</t>
<figure>
<artwork><![CDATA[
NOTIFY alice@atlanta.example.com SIP/2.0
Subscription-State: active; expires=7200
....
From: <sip:bob@biloxi.example.com>;tag=1234
Identity: ".... stuff removed ...."
Identity-Info: <https://atlanta.example.com/cert>;alg=rsa-sha256
....
Event: certificate
Content-Type: application/pkix-cert
Content-Disposition: signal
< certificate data >
]]></artwork>
</figure>
<t>Next, Alice sends a SIP MESSAGE message to Bob and can encrypt the
body using Bob's public key as shown below.</t>
<figure>
<artwork><![CDATA[
MESSAGE sip:bob@biloxi.example.com SIP/2.0
...
Content-Type: application/pkcs7-mime
Content-Disposition: render
$ Content-Type: text/plain
$
$ < encrypted version of "Hello" >
]]></artwork>
</figure>
</section>
<section title="Setting and Retrieving UA Credentials">
<t>When Alice's UA wishes to publish Alice's certificate and private
key to the credential service, it sends a PUBLISH request like the one
below. This must be sent over a TLS connection directly to the domain
of the credential service. The credential service presents a
certificate where the SubjectAltName contains an entry that matches
the domain name in the request line of the PUBLISH request and digest
challenges the request to authenticate her.</t>
<figure>
<artwork><![CDATA[
PUBLISH sips:alice@atlanta.example.com SIP/2.0
...
Event: credential
Content-Type: multipart/mixed;boundary=boundary
Content-Disposition: signal
--boundary
Content-ID: 123
Content-Type: application/pkix-cert
< Public certificate for Alice >
--boundary
Content-ID: 456
Content-Type: application/pkcs8
< Private Key for Alice >
--boundary
]]></artwork>
</figure>
<t>If one of Alice's UAs subscribes to the credential event, the UA
will be digest challenged, and the NOTIFY will include a body similar
to the one in the PUBLISH section above.</t>
</section>
</section>
<section title="Security Considerations">
<t>The high level message flow from a security point of view is
summarized in the following figure. The 200 responses are removed from
the figure as they do not have much to do with the overall security.</t>
<t>In this figure, authC refers to authentication and authZ refers to
authorization.</t>
<figure>
<artwork><![CDATA[
Alice Server Bob UA
| | TLS Handshake | 1) Client authC/Z server
| |<---------------->|
| | PUBLISH | 2) Client sends request
| |<-----------------| (write credential)
| | Digest Challenge | 3) Server challenges client
| |----------------->|
| | PUBLISH + Digest | 4) Server authC/Z client
| |<-----------------|
| | time... |
| | |
| | TLS Handshake | 5) Client authC/Z server
| |<---------------->|
| | SUBSCRIBE | 6) Client sends request
| |<-----------------| (read credential)
| | Digest Challenge | 7) Server challenges client
| |----------------->|
| | SUBSCRIBE+Digest | 8) Server authC/Z client
| |<-----------------|
| | NOTIFY | 9) Server returns credential
| |----------------->|
| |
| SUBSCRIBE | 10) Client requests certificate
|---------->|
| |
|NOTIFY+AUTH| 11) Server returns user's certificate and signs that
|<----------| it is valid using certificate for the domain
| |
]]></artwork>
</figure>
<t>When the UA, labeled Bob, first created a credential for Bob, it
would store this on the credential server. The UA authenticated the
Server using the certificates from the TLS handshake. The Server
authenticated the UA using a digest style challenge with a shared
secret.</t>
<t>The UA, labeled Bob, wishes to request its credentials from the
server. First it forms a TLS connection to the Server, which provides
integrity and privacy protection and also authenticates the server to
Bob's UA. Next the UA requests its credentials using a SUBSCRIBE
request. The Server digest challenges this to authenticate Bob's UA. The
server and Bob's UA have a shared secret that is used for this. If the
authentication is successful, the server sends the credentials to Bob's
UA. The private key in the credentials may have been encrypted using a
shared secret that the server does not know.</t>
<t>A similar process would be used for Bob's UA to publish new
credentials to the server. Bob's UA would send a PUBLISH request
containing the new credentials. When this happened, all the other UAs
that were subscribed to Bob's credentials would receive a NOTIFY with
the new credentials.</t>
<t>Alice wishes to find Bob's certificate and sends a SUBSCRIBE to the
server. The server sends the response in a NOTIFY. This does not need to
be sent over a privacy or integrity protected channel, as the
Authentication service described in <xref target="RFC4474"></xref>
provides integrity protection of this information and signs it with the
certificate for the domain.</t>
<t>This whole scheme is highly dependent on trusting the operators of
the credential service and trusting that the credential service will not
be compromised. The security of all the users will be compromised if the
credential service is compromised.</t>
<t><list>
<t>Note: There has been significant discussion of the topic of
avoiding deployments in which the credential servers store the
private keys, even in some encrypted form that the credential server
does not know how to decrypt. Various schemes were considered to
avoid this but they all result in either moving the problem to some
other server, which does not seem to make the problem any better, or
having a different credential for each device. For some deployments
where each user has only one device this is fine but for deployments
with multiple devices, it would require that when Alice went to
contact Bob, Alice would have to provide messages encrypted for all
of Bob's devices. The sipping working group did consider this
architecture and decided it was not appropriate due both to the
information it revealed about the devices and users and the amount
of signaling required to make it work.</t>
</list></t>
<t>This specification requires that TLS be used for the SIP
communications to place and retrieve a UA's private key. This provides
security in two ways: <list style="numbers">
<t>Confidentiality is provided for the digest authentication
exchange, thus protecting it from dictionary attacks.</t>
<t>Confidentiality is provided for the private key, thus protecting
it from being exposed to passive attackers.</t>
</list> In order to prevent man-in-the-middle attacks, TLS clients
MUST check that the SubjectAltName of the certificate for the server
they connected to exactly matches the server they were trying to connect
to. The connection must be directly connected to the correct server or
any intermediaries in the TLS path can compromise the certificate and
instead provide a certificate for which the attacker knows the private
key. This may lead the UA that relies on this compromised certificate to
lose confidential information. Failing to use TLS or selecting a poor
cipher suite (such as NULL encryption) may result in credentials,
including private keys, being sent unencrypted over the network and will
render the whole system useless.</t>
<t>The correct checking of chained certificates as specified in <xref
target="RFC5246">TLS</xref> is critical for the client to authenticate
the server. If the client does not authenticate that it is talking to
the correct credential service, a man in the middle attack is
possible.</t>
<!--
<t>
If a UA receives a certificate in a TLS connection that it cannot chain
back to a well known certification authority but is otherwise valid (i.e. a self-signed
certificate), it MAY ask the user if it wishes to allow this certificate
to be used, and if so, add it to the store of trusted certificates for
TLS connections and for verifying Identity header fields. When asking if a
certificate can be used, the device SHOULD provide the SHA-1 fingerprint
of the certificate to the user. Since users seldom check the fingerprint
of a certificate, accepting the certificate results in a leap of faith
that the TLS connection was not made to an attacker when the certificate
was accepted. Subsequent connections to the same server are secure as
long as the initial connection in which the certificate was accepted was
not compromised.</t>
-->
<section anchor="section.revocation" title="Certificate Revocation">
<t>If a particular credential needs to be revoked, the new credential
is simply published to the credential service. Every device with a
copy of the old credential or certificate in its cache will have a
subscription and will rapidly (order of seconds) be notified and
replace its cache. Clients that are not subscribed will subscribe when
they next need to use the certificate and will get the new
certificate.</t>
<t>It is possible that an attacker could mount a DOS attack such that
the UA that had cached a certificate did not receive the NOTIFY with
its revocation. To protect against this attack, the UA needs to limit
how long it caches certificates. After this time, the UA would
invalidate the cached information even though no NOTIFY had ever been
received due to the attacker blocking it.</t>
<t>The duration of this cached information is in some ways similar to
a device deciding how often to check a CRL list. For many
applications, a default time of 1 day is suggested, but for some
applications it may be desirable to set the time to zero so that no
certificates are cached at all and the credential is checked for
validity every time the certificate is used.</t>
<t>The UA MUST NOT cache the certificates for a period longer than
that of the subscription duration. This is to avoid the UA using
invalid cached credentials when the notifier of the new credentials
has been prevented from updating the UA.</t>
</section>
<section anchor="section.replacement" title="Certificate Replacement">
<t>The UAs in the system replace the certificates close to the time
that the certificates would expire. If a UA has used the same key pair
to encrypt a very large volume of traffic, the UA MAY choose to
replace the credential with a new one before the normal
expiration.</t>
</section>
<section anchor="trust" title="Trusting the Identity of a Certificate">
<t>When a UA wishes to discover the certificate for
sip:alice@example.com, the UA subscribes to the certificate for
alice@example.com and receives a certificate in the body of a SIP
NOTIFY request. The term original URI is used to describe the URI that
was in the To header field value of the SUBSCRIBE request. So in this
case the original URI would be sip:alice@example.com.</t>
<t>If the certificate is signed by a trusted certification authority,
and one of the names in the SubjectAltName matches the original URI,
then this certificate MAY be used but only for exactly the original
URI and not for other identities found in the SubjectAltName.
Otherwise, there are several steps the UA MUST perform before using
this certificate. <list style="symbols">
<t>The From header field in the NOTIFY request MUST match the
original URI that was subscribed to.</t>
<t>The UA MUST check the Identity header field as described in the
<xref target="RFC4474"> Identity </xref> specification to validate
that bodies have not been tampered with and that an Authentication
Service has validated this From header field.</t>
<t>The UA MUST check the validity time of the certificate and stop
using the certificate if it is invalid. (Implementations are
reminded to verify both the notBefore and notAfter validity
times.)</t>
<t>The certificate MAY have several names in the SubjectAltName
but the UA MUST only use this certificate when it needs the
certificate for the identity asserted by the Authentication
Service in the NOTIFY. This means that the certificate should only
be indexed in the certificate cache by the AOR that the
Authentication Service asserted and not by the value of all the
identities found in the SubjectAltName list.</t>
</list> These steps result in a chain of bindings that result in a
trusted binding between the original AOR that was subscribed to and a
public key. The original AOR is forced to match the From. The
Authentication Service validates that this request did come from the
identity claimed in the From header field value and that the bodies in
the request that carry the certificate have not been tampered with.
The certificate in the body contains the public key for the identity.
Only the UA that can authenticate as this AOR, or devices with access
to the private key of the domain, can tamper with this body. This
stops other users from being able to provide a false public key. This
chain of assertion from original URI, to From, to body, to public key
is critical to the security of the mechanism described in this
specification. If any of the steps above are not followed, this chain
of security will be broken and the system will not work.</t>
<section anchor="cert.extra" title="Extra Assurance">
<t>Although the certificates used with this document need not be
validatable to a trust anchor via <xref target="RFC5280">PKIX</xref>
procedures, certificates which can be validated may also be
distributed via this mechanism. Such certificates potentially offer
an additional level of security because they can be used with the
secure (and partially isolated) certification authority user
verification and key issuance toolset, rather than depending on the
security of generic SIP implementations.</t>
<t>When a relying party receives a certificate which is not
self-signed, it MAY attempt to validate it using the rules in
Section 6 of <xref target="RFC5280"></xref>. If the certificate
validates successfully and the names correctly match the user's AOR
(see <xref target="cert.gen"></xref>), then the implementation
SHOULD provide some indication that the certificate has been
validated with an external authority. In general, failure to
validate a certificate via this mechanism SHOULD NOT be used as a
reason to reject the certificate. However, if the certificate is
revoked, then the implementation SHOULD reject it.</t>
</section>
</section>
<section title="SACRED Framework">
<t>This specification includes a mechanism that allows end users to
share the same credentials across different end-user devices. This
mechanism is based on the one presented in the <xref
target="RFC3760">SACRED Framework</xref>. While this mechanism is
fully described in this document, the requirements and background are
more thoroughly discussed in <xref target="RFC3760"></xref>.</t>
<t>Specifically, <xref target="subscriber.behavior"></xref>, <xref
target="notifier.subscribe.behavior"></xref> and <xref
target="notifier.publish.behavior"></xref> follow the cTLS
architecture described in section 4.2.2 of <xref
target="RFC3760"></xref>. The client authenticates the server using
the server's TLS certificate. The server authenticates the client
using a SIP digest transaction inside the TLS session. The TLS
sessions form a strong session key that is used to protect the
credentials being exchanged.</t>
</section>
<section anchor="sec-pwd" title="Crypto Profiles">
<t>Credential Services SHOULD implement the server name indication
extensions in <xref target="RFC4366"></xref>. As specified in <xref
target="RFC5246"></xref>, Credential Services MUST support the TLS
cipher suite TLS_RSA_WITH_AES_128_CBC_SHA. In addition, they MUST
support the TLS cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256 as
specified in <xref target="RFC5246"></xref>. If additional cipher
suites are supported, then implementations MUST NOT negotiate a cipher
suite that employs NULL encryption, integrity, or authentication
algorithms.</t>
<t>Implementations of TLS typically support multiple versions of the
Transport Layer Security protocol as well as the older Secure Sockets
Layer (SSL) protocol. Because of known security vulnerabilities,
clients and servers MUST NOT request, offer, or use SSL 2.0. See
Appendix E.2 of <xref target="RFC5246"></xref>for further details.</t>
<t>The PKCS#8 in the clients MUST implement PBES2 with a key
derivation algorithm of PBKDF2 using HMAC with SHA-256 <xref
target="RFC5754"></xref> and an encryption algorithm of
id-aes128-wrap-pad as defined in <xref target="RFC5649"></xref>. Some
pre-standard deployments of this specification used DES-EDE2-CBC-Pad
as defined in <xref target="RFC2898"></xref> so, for some
implementations, it may be desirable to also support that algorithm. A
different passphrase SHOULD be used for the PKCS#8 encryption than is
used for authentication of the client. It is important to choose an
sufficiently strong passphrases. Specific advice on the passphrase can
be found in section 6 of <xref
target="I-D.turner-asymmetrickeyformat"></xref>.</t>
</section>
<section anchor="cert.gen" title="User Certificate Generation">
<t>The certificates need to be consistent with <xref
target="RFC5280"></xref>. The sha1WithRSAEncryption and
sha256WithRSAEncryption algorithm for the signatureAlgorithm MUST be
implemented. The Issuers SHOULD be the same as the subject. Given the
ease of issuing new certificates with this system, the Validity can be
relatively short. A Validity of one year or less is RECOMMENDED. The
SubjectAltName must have a URI type that is set to the SIP URL
corresponding to the user AOR. It MAY be desirable to put some
randomness into the length of time for which the certificates are
valid so that it does not become necessary to renew all the
certificates in the system at the same time.</t>
<t>When creating a new key pair for a certificate, it is critical to
have appropriate randomness as described in <xref
target="RFC4086"></xref>. This can be challenging on some embedded
devices such as some IP Phones and implementors should pay particular
attention to this point.</t>
<t>It is worth noting that a UA can discover the current time by
looking at the Date header field value in the 200 response to a
REGISTER request.</t>
</section>
<section title="Private Key Storage">
<t>The protection afforded private keys is a critical security factor.
On a small scale, failure of devices to protect the private keys will
permit an attacker to masquerade as the user or decrypt their personal
information. As noted in the SACRED Framework <xref
target="RFC3760"></xref>, when stored on an end user device, such as a
diskette or hard drive, credentials SHOULD NOT be in the clear.</t>
</section>
<section title="Compromised Authentication Service">
<t>One of this worst attacks against this system would be if the
Authentication Service were compromised. This attack is somewhat
analogous to a certification authority being compromised in
traditional PKI systems. The attacker could make a fake certificate
for which it knows the private key, use it to receive any traffic for
a given use, and then re-encrypt that traffic with the correct key and
forward the communication to the intended receiver. The attacker would
thus become a man in the middle in the communications.</t>
<t>There is not too much that can be done to protect against this. A
UA MAY subscribe to its own certificate under some other identity to
try to detect whether the credential server is handing out the correct
certificates. It will be difficult to do this in a way that does not
allow the credential server to recognize the user's UA.</t>
<t>The UA MAY also save the fingerprints of the cached certificates
and warn users when the certificates change significantly before their
expiry date.</t>
<t>The UA MAY also allow the user to see the fingerprints for the
cached certificates so that they can be verified by some other out of
band means.</t>
</section>
</section>
<section title="IANA Considerations">
<t>This specification defines two new event packages that IANA is
requested to add the registry at: <list>
<t>http://www.iana.org/assignments/sip-events</t>
</list></t>
<section title="Certificate Event Package">
<figure>
<artwork><![CDATA[
To: ietf-sip-events@iana.org
Subject: Registration of new SIP event package
Package Name: certificate
Is this registration for a Template Package: No
Published Specification(s): This document
New Event header parameters: This package defines no
new parameters
Person & email address to contact for further information:
Cullen Jennings <fluffy@cisco.com>
]]></artwork>
</figure>
</section>
<section title="Credential Event Package">
<figure>
<artwork><![CDATA[
To: ietf-sip-events@iana.org
Subject: Registration of new SIP event package
Package Name: credential
Is this registration for a Template Package: No
Published Specification(s): This document
Person & email address to contact for further information:
Cullen Jennings <fluffy@cisco.com>
]]></artwork>
</figure>
</section>
<!--
<section title="PKCS#8">
<figure>
<artwork><![CDATA[
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkcs8
MIME media type name: application
MIME subtype name: pkcs8
Required parameters: None
Optional parameters: None
Encoding considerations: binary
Security considerations: Carries a cryptographic private key
Interoperability considerations:
The PKCS#8 object inside this MIME type MUST be DER-encoded
Published specification:
Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8:
Private-Key Information Syntax Specification Version 1.2",
RFC 5208, May 2008.
Applications which use this media type: Any MIME-compliant transport
Additional information:
Magic number(s): None
File extension(s): .p8
Macintosh File Type Code(s): none
Person & email address to contact for further information:
Cullen Jennings <fluffy@cisco.com>
Intended usage: COMMON
Author/Change controller:
the IESG
]]></artwork>
</figure>
</section>
-->
<section anchor="sec:iana-alg" title="Identity Algorithm">
<t>IANA will add the following entry to the "Identity-Info Algorithm
Parameter Values" registry. Note to RFC Editor: Please replace RFCAAAA
with the number for this RFC.</t>
<figure>
<artwork><![CDATA[
'alg' Parameter Name Reference
---------------------- ---------
rsa-sha256 [RFCAAAA]
]]></artwork>
</figure>
</section>
</section>
<section title="Acknowledgments">
<t>Many thanks to Eric Rescorla, Russ Housley, Jim Schaad, Rohan Mahy
for significant help and discussion. Many others provided useful
comments, including Kumiko Ono, Peter Gutmann, Yaron Pdut, Aki Niemi,
Magnus Nystrom, Paul Hoffman, Adina Simu, Dan Wing, Mike Hammer, Pasi
Eronen, Alexey Melnikov, Tim Polk and Lyndsay Campbell. Rohan Mahy, John
Elwell, and Jonathan Rosenberg provided detailed review and text.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2046.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2585.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3204.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3265.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3903.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml"?>
<!--
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5208.xml"?>
-->
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4366.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5754.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5649.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.turner-asymmetrickeyformat.xml"?>
</references>
<references title="Informational References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2898.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3760.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3851.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3853.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4662.xml"?>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 20:41:36 |