draft-ietf-oauth-introspection-05.txt   draft-ietf-oauth-introspection-06.txt 
OAuth Working Group J. Richer, Ed. OAuth Working Group J. Richer, Ed.
Internet-Draft Internet-Draft March 23, 2015
Intended status: Standards Track February 9, 2015 Intended status: Standards Track
Expires: August 13, 2015 Expires: September 24, 2015
OAuth 2.0 Token Introspection OAuth 2.0 Token Introspection
draft-ietf-oauth-introspection-05 draft-ietf-oauth-introspection-06
Abstract Abstract
This specification defines a method for a protected resource to query This specification defines a method for a protected resource to query
an OAuth 2.0 authorization server to determine the active state of an an OAuth 2.0 authorization server to determine the active state of an
OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 token and to determine meta-information about this token.
OAuth 2.0 deployments can use this method to convey information about OAuth 2.0 deployments can use this method to convey information about
the authorization context of the token from the authorization server the authorization context of the token from the authorization server
to the protected resource. to the protected resource.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 13, 2015. This Internet-Draft will expire on September 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introspection Endpoint . . . . . . . . . . . . . . . . . . . 3 2. Introspection Endpoint . . . . . . . . . . . . . . . . . . . 3
2.1. Introspection Request . . . . . . . . . . . . . . . . . . 4 2.1. Introspection Request . . . . . . . . . . . . . . . . . . 3
2.2. Introspection Response . . . . . . . . . . . . . . . . . 5 2.2. Introspection Response . . . . . . . . . . . . . . . . . 5
2.3. Error Response . . . . . . . . . . . . . . . . . . . . . 7 2.3. Error Response . . . . . . . . . . . . . . . . . . . . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Document History . . . . . . . . . . . . . . . . . . 11 Appendix A. Use with Proof of Posession Tokens . . . . . . . . . 13
Appendix B. Use with Proof of Posession Tokens . . . . . . . . . 12 Appendix B. Document History . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
In OAuth 2.0, the contents of tokens are opaque to clients. This In OAuth 2.0, the contents of tokens are opaque to clients. This
means that the client does not need to know anything about the means that the client does not need to know anything about the
content or structure of the token itself, if there is any. However, content or structure of the token itself, if there is any. However,
there is still a large amount of metadata that may be attached to a there is still a large amount of metadata that may be attached to a
token, such as its current validity, approved scopes, and information token, such as its current validity, approved scopes, and information
about the context in which the token was issued. These pieces of about the context in which the token was issued. These pieces of
information are often vital to protected resources making information are often vital to protected resources making
authorization decisions based on the tokens being presented. Since authorization decisions based on the tokens being presented. Since
OAuth 2.0 [RFC6749] defines no direct relationship between the OAuth 2.0 [RFC6749] does not define a protocol for the resource
authorization server and the protected resource, only that they must server to learn meta-information about a token that is has received
have an agreement on the tokens themselves, there have been many from an authorization server, several different approaches have been
different approaches to bridging this gap. These include using developed to bridge this gap. These include using structured token
structured token formats such as JWT [JWT] or proprietary inter- formats such as JWT [JWT] or proprietary inter-service communication
service communication mechanisms (such as shared databases and mechanisms (such as shared databases and protected enterprise service
protected enterprise service buses) that convey token information. buses) that convey token information.
This specification defines an interoperable web API that allows This specification defines an interoperable web API that allows
authorized protected resources to query the authorization server to authorized protected resources to query the authorization server to
determine the set of metadata for a given token that was presented to determine the set of metadata for a given token that was presented to
them by an OAuth 2.0 client. This metadata includes whether or not them by an OAuth 2.0 client. This metadata includes whether or not
the token is currently active (or if it has expired or otherwise been the token is currently active (or if it has expired or otherwise been
revoked), what rights of access the token carries (usually conveyed revoked), what rights of access the token carries (usually conveyed
through OAuth 2.0 scopes), and the authorization context in which the through OAuth 2.0 scopes), and the authorization context in which the
token was granted (including who authorized the token and which token was granted (including who authorized the token and which
client it was issued to). Token introspection allows a protected client it was issued to). Token introspection allows a protected
skipping to change at page 3, line 42 skipping to change at page 3, line 42
The introspection endpoint is an OAuth 2.0 endpoint that takes a The introspection endpoint is an OAuth 2.0 endpoint that takes a
parameter representing an OAuth 2.0 token and returns a JSON parameter representing an OAuth 2.0 token and returns a JSON
[RFC7159] document representing the meta information surrounding the [RFC7159] document representing the meta information surrounding the
token, including whether this token is currently active. The token, including whether this token is currently active. The
definition of an active token is up to the authorization server, but definition of an active token is up to the authorization server, but
this is commonly a token that has been issued by this authorization this is commonly a token that has been issued by this authorization
server, is not expired, has not been revoked, and is within the server, is not expired, has not been revoked, and is within the
purview of the protected resource making the introspection call. purview of the protected resource making the introspection call.
The introspection endpoint MUST be protected by TLS of at least The introspection endpoint MUST be protected by a transport-layer
version 1.2 RFC 5246 [RFC5246] and MAY support additional transport- security mechanism as described in Section 4.
layer mechanisms meeting its security requirements. When using TLS,
the protected resource MUST perform a TLS/SSL server certificate
check, per RFC 6125 [RFC6125]. Implementation security
considerations can be found in Recommendations for Secure Use of TLS
and DTLS [TLS.BCP].
2.1. Introspection Request 2.1. Introspection Request
The protected resource calls the introspection endpoint using an HTTP The protected resource calls the introspection endpoint using an HTTP
POST [RFC7231] request with parameters sent as "application/x-www- POST [RFC7231] request with parameters sent as "application/x-www-
form-urlencoded" data as defined in [W3C.REC-html5-20141028]. The form-urlencoded" data as defined in [W3C.REC-html5-20141028]. The
authorization server MAY allow an HTTP GET [RFC7231] request with authorization server MAY allow an HTTP GET [RFC7231] request with
parameters passed in the query string as defined in parameters passed in the query string as defined in
[W3C.REC-html5-20141028]. The protected resource sends a parameter [W3C.REC-html5-20141028]. The protected resource sends a parameter
representing the token along with optional parameters representing representing the token along with optional parameters representing
additional context that is known by the protected resource to aid the additional context that is known by the protected resource to aid the
authorization server in its response. authorization server in its response.
token REQUIRED. The string value of the token. For access tokens, token REQUIRED. The string value of the token. For access tokens,
this is the "access_token" value returned from the token endpoint this is the "access_token" value returned from the token endpoint
defined in OAuth 2.0 [RFC6749] section 5.1. For refresh tokens, defined in OAuth 2.0 [RFC6749] section 5.1. For refresh tokens,
this is the "refresh_token" value returned from the token endpoint this is the "refresh_token" value returned from the token endpoint
as defined in OAuth 2.0 [RFC6749] section 5.1. Other token types as defined in OAuth 2.0 [RFC6749] section 5.1. Other token types
skipping to change at page 5, line 36 skipping to change at page 5, line 36
token=mF_9.B5f-4.1JqM&token_type_hint=access_token token=mF_9.B5f-4.1JqM&token_type_hint=access_token
2.2. Introspection Response 2.2. Introspection Response
The server responds with a JSON object [RFC7159] in "application/ The server responds with a JSON object [RFC7159] in "application/
json" format with the following top-level members. json" format with the following top-level members.
active active
REQUIRED. Boolean indicator of whether or not the presented token REQUIRED. Boolean indicator of whether or not the presented token
is currently active. The authorization server determines whether is currently active. The specifics of a token's "active" state
and when a given token is in an active state. will vary depending on the implementation of the authorization
server, and the information it keeps about its tokens, but a
"true" value return for the "active" property will generally
indicate that a given token has been issued by this authorization
server, has not been revoked by the resource owner, and is within
its given time window of validity (e.g. After its issuance time
but not yet expired). See Section 4 for information on
implementation of such checks.
scope scope
OPTIONAL. A space-separated list of strings representing the OPTIONAL. A space-separated list of strings representing the
scopes associated with this token, in the format described in scopes associated with this token, in the format described in
section 3.3 of OAuth 2.0 [RFC6749]. section 3.3 of OAuth 2.0 [RFC6749].
client_id client_id
OPTIONAL. Client identifier for the OAuth 2.0 client that OPTIONAL. Client identifier for the OAuth 2.0 client that
requested this token. requested this token.
user_id username
OPTIONAL. Human-readable identifier for the user who authorized OPTIONAL. Human-readable identifier for the resource owner who
this token. authorized this token.
token_type token_type
OPTIONAL. Type of the token as defined in section 5.1 of OAuth OPTIONAL. Type of the token as defined in section 5.1 of OAuth
2.0 [RFC6749]. 2.0 [RFC6749].
The response MAY include any claims defined as JWT [JWT] claim names The response MAY include any claims defined as JWT [JWT] claim names
and carry the same semantics and syntax, such as the following: and carry the same semantics and syntax, such as the following:
exp exp
OPTIONAL. Integer timestamp, measured in the number of seconds OPTIONAL. Integer timestamp, measured in the number of seconds
skipping to change at page 6, line 51 skipping to change at page 7, line 12
service-specific pieces of information as top-level members of this service-specific pieces of information as top-level members of this
JSON object. JSON object.
The authorization server MAY respond differently to different The authorization server MAY respond differently to different
protected resources making the same request. For instance, an protected resources making the same request. For instance, an
authorization server MAY limit which scopes from a given token for authorization server MAY limit which scopes from a given token for
each protected resources in order to prevent protected resources from each protected resources in order to prevent protected resources from
learning more about the larger network than is necessary for their learning more about the larger network than is necessary for their
function. function.
The response MAY be cached by the protected resource. The response MAY be cached by the protected resource to improve
performance and reduce load on the introspection endpoint, but at the
cost of liveness of the information used by the protected resource.
See Section 4 for more information regarding the trade off when the
response is cached.
For example, the following response contains a set of information For example, the following response contains a set of information
about an active token: about an active token:
Following is a non-normative example response: Following is a non-normative example response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
{ {
"active": true, "active": true,
"client_id": "l238j323ds-23ij4", "client_id": "l238j323ds-23ij4",
"user_id": "jdoe", "username": "jdoe",
"scope": "read write dolphin", "scope": "read write dolphin",
"sub": "Z5O3upPC88QrAjx00dis", "sub": "Z5O3upPC88QrAjx00dis",
"aud": "https://protected.example.net/resource", "aud": "https://protected.example.net/resource",
"iss": "https://server.example.com/", "iss": "https://server.example.com/",
"exp": 1419356238, "exp": 1419356238,
"iat": 1419350238, "iat": 1419350238,
"extension_field": "twenty-seven" "extension_field": "twenty-seven"
} }
If the introspection call is properly authorized but the token is not If the introspection call is properly authorized but the token is not
skipping to change at page 8, line 31 skipping to change at page 8, line 45
3. IANA Considerations 3. IANA Considerations
This specification requests IANA to register the following values This specification requests IANA to register the following values
into the IANA JSON Web Token Claims registry for JWT Claim Names. into the IANA JSON Web Token Claims registry for JWT Claim Names.
o Claim Name: "active" o Claim Name: "active"
o Claim Description: Token active status o Claim Description: Token active status
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.2 of [[ this document ]]. o Specification Document(s): Section 2.2 of [[ this document ]].
o Claim Name: "user_id" o Claim Name: "username"
o Claim Description: User identifier of the resource owner o Claim Description: User identifier of the resource owner
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.2 of [[ this document ]]. o Specification Document(s): Section 2.2 of [[ this document ]].
o Claim Name: "client_id" o Claim Name: "client_id"
o Claim Description: Client identifier of the client o Claim Description: Client identifier of the client
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.2 of [[ this document ]]. o Specification Document(s): Section 2.2 of [[ this document ]].
o Claim Name: "scope" o Claim Name: "scope"
skipping to change at page 9, line 7 skipping to change at page 9, line 19
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.2 of [[ this document ]]. o Specification Document(s): Section 2.2 of [[ this document ]].
o Claim Name: "token_type" o Claim Name: "token_type"
o Claim Description: Type of the token o Claim Description: Type of the token
o Change Controller: IESG o Change Controller: IESG
o Specification Document(s): Section 2.2 of [[ this document ]]. o Specification Document(s): Section 2.2 of [[ this document ]].
4. Security Considerations 4. Security Considerations
Since there are many different and valid ways to implement an OAuth
2.0 system, there are consequently many ways for an authorization
server to determine whether or not a token is currently "active" or
not. However, since resource servers using token introspection rely
on the authorization server to determine the state of a token, the
authorization server MUST perform all applicable checks against a
token's state. For instance:
o If the token can expire, the authorization server MUST determine
whether or not the token has expired.
o If the token can be issued before it is able to be used, the
authorization server MUST determine whether or not a token's valid
period has started yet.
o If the token can be revoked after it was issued, the authorization
server MUST determine whether or not such a revocation has taken
place.
o If the token has been signed, the authorization server MUST
validate the signature.
If an authorization server fails to perform any applicable check, the
resource server could make an errant security decision based on that
response. Note that not all of these checks will be applicable to
all OAuth 2.0 deployments and it is up to the authorization server to
determine which of these checks (and any other checks) apply.
If left unprotected and un-throttled, the introspection endpoint If left unprotected and un-throttled, the introspection endpoint
could present a means for an attacker to poll a series of possible could present a means for an attacker to poll a series of possible
token values, fishing for a valid token. To prevent this, the token values, fishing for a valid token. To prevent this, the
authorization server MUST require authentication of protected authorization server MUST require authentication of protected
resources that need to access the introspection endpoint and SHOULD resources that need to access the introspection endpoint and SHOULD
require protected resources to be specifically authorized to call the require protected resources to be specifically authorized to call the
introspection endpoint. The specifics of this authentication introspection endpoint. The specifics of this authentication
credentials are out of scope of this specification, but commonly credentials are out of scope of this specification, but commonly
these credentials could take the form of any valid client these credentials could take the form of any valid client
authentication mechanism used with the token endpoint, an OAuth 2.0 authentication mechanism used with the token endpoint, an OAuth 2.0
access token, or other HTTP authorization or authentication access token, or other HTTP authorization or authentication
mechanism. A single piece of software acting as both a client and a mechanism. A single piece of software acting as both a client and a
protected resource MAY re-use the same credentials between the token protected resource MAY re-use the same credentials between the token
endpoint and the introspection endpoint, though doing so potentially endpoint and the introspection endpoint, though doing so potentially
conflates the activities of the client and protected resource conflates the activities of the client and protected resource
portions of the software and the authorization server MAY require portions of the software and the authorization server MAY require
separate credentials for each mode. separate credentials for each mode.
Since the introspection endpoint takes in OAuth 2.0 tokens as Since the introspection endpoint takes in OAuth 2.0 tokens as
parameters, the server MUST support TLS 1.2 RFC 5246 [RFC5246] and parameters and responds with information used to make authorization
MAY support additional transport-layer mechanisms meeting its decisions, the server MUST support TLS 1.2 RFC 5246 [RFC5246] and MAY
security requirements. When using TLS, the client or protected support additional transport-layer mechanisms meeting its security
resource MUST perform a TLS/SSL server certificate check, per RFC requirements. When using TLS, the client or protected resource MUST
6125 [RFC6125]. Implementation security considerations can be found perform a TLS/SSL server certificate check, per RFC 6125 [RFC6125].
in Recommendations for Secure Use of TLS and DTLS [TLS.BCP]. Implementation security considerations can be found in
Recommendations for Secure Use of TLS and DTLS [TLS.BCP].
In order to prevent the values of access tokens being from leaking In order to prevent the values of access tokens being from leaking
into server-side logs via query parameters, an authorization server into server-side logs via query parameters, an authorization server
offering token introspection MAY disallow HTTP GET and instead offering token introspection MAY disallow HTTP GET and instead
require an HTTP POST method only to the introspection endpoint. require an HTTP POST method to be used at the introspection endpoint.
In order to avoid disclosing internal server state, an introspection In order to avoid disclosing internal server state, an introspection
response for an inactive token SHOULD NOT contain any additional response for an inactive token SHOULD NOT contain any additional
claims beyond the required "active" claim (with its value set to claims beyond the required "active" claim (with its value set to
"false"). "false").
Since a protected resource MAY cache the response of the
introspection endpoint, designers of an OAuth 2.0 system using this
protocol MUST consider the performance and security trade-offs
inherent in caching security information such as this. A less
aggressive cache with a short timeout will provide the protected
resource with more up to date information (due to it needing to query
the introspection endpoint more often) at the cost of increased
network traffic and load on the introspection endpoint. A more
aggressive cache with a longer duration will minimize network traffic
and load on the introspection endpoint, but at the cost of liveness
of information about the token. For example, the token may be
revoked while the protected resource is relying on the value of the
cached response to make authorization decisions. This creates a
window during which a revoked token could be used at the protected
resource. Consequently, an acceptable cache validity duration needs
to be carefully considered given the concerns and sensitivities of
the protected resource being accessed and the likelihood of a token
being revoked or invalidated in the interim period. Highly sensitive
environments can opt to disable caching entirely on the protected
resource in order to maximize liveness of information.
An authorization server offering token introspection MUST be able to An authorization server offering token introspection MUST be able to
understand the token values being presented to it during this call. understand the token values being presented to it during this call.
The exact means by which this happens is an implementation detail and The exact means by which this happens is an implementation detail and
outside the scope of this specification. For unstructured tokens, outside the scope of this specification. For unstructured tokens,
this could take the form of a simple server-side database query this could take the form of a simple server-side database query
against a data store containing the context information for the against a data store containing the context information for the
token. For structured tokens, this could take the form of the server token. For structured tokens, this could take the form of the server
parsing the token, validating its signature or other protection parsing the token, validating its signature or other protection
mechanisms, and returning the information contained in the token back mechanisms, and returning the information contained in the token back
to the protected resource (allowing the protected resource to be to the protected resource (allowing the protected resource to be
skipping to change at page 11, line 34 skipping to change at page 13, line 5
7.2. Informative References 7.2. Informative References
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token (work in (JWT)", draft-ietf-oauth-json-web-token (work in
progress), July 2014. progress), July 2014.
[TLS.BCP] Sheffer, Y., Holz, R., and P. Saint-Andre, [TLS.BCP] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", November "Recommendations for Secure Use of TLS and DTLS", November
2014. 2014.
Appendix A. Document History Appendix A. Use with Proof of Posession Tokens
With bearer tokens such as those defined by OAuth 2.0 Bearer Token
Usage [RFC6750], the protected resource will have in its possession
the entire secret portion of the token for submission to the
introspection service. However, for proof-of-possession style
tokens, the protected resource will have only a token identifier used
during the request, along with the cryptographic signature on the
request. The protected resource would be able to submit the token
identifier to the authorization server's token endpoint in order to
obtain the necessary key information needed to validate the signature
on the request. The details of this usage are outside the scope of
this specification and will be defined in an extension to this
specification.
Appendix B. Document History
[[ To be removed by the RFC Editor. ]] [[ To be removed by the RFC Editor. ]]
-06
o Clarified relationship between AS and RS in introduction.
o Used updated TLS text imported from Dyn-Reg drafts.
o Clarified definition of active state.
o Added some advice on caching responses.
o Added security considerations on active state implementation.
o Changed user_id to username based on WG feedback.
-05 -05
o Typo fix. o Typo fix.
o Updated author information. o Updated author information.
o Removed extraneous "linewrap" note from examples. o Removed extraneous "linewrap" note from examples.
- 04 - 04
skipping to change at page 12, line 37 skipping to change at page 14, line 37
o Clarified that authorization servers need to be able to understand o Clarified that authorization servers need to be able to understand
the token if they're to introspect it. the token if they're to introspect it.
o Various editorial cleanups. o Various editorial cleanups.
- 00 - 00
o Created initial IETF drafted based on draft-richer-oauth- o Created initial IETF drafted based on draft-richer-oauth-
introspection-06 with no normative changes. introspection-06 with no normative changes.
Appendix B. Use with Proof of Posession Tokens
With bearer tokens such as those defined by OAuth 2.0 Bearer Token
Usage [RFC6750], the protected resource will have in its possession
the entire secret portion of the token for submission to the
introspection service. However, for proof-of-possession style
tokens, the protected resource will have only a token identifier used
during the request, along with the cryptographic signature on the
request. The protected resource would be able to submit the token
identifier to the authorization server's token endpoint in order to
obtain the necessary key information needed to validate the signature
on the request. The details of this usage are outside the scope of
this specification and should be defined in an extension to this
specification.
Author's Address Author's Address
Justin Richer (editor) Justin Richer (editor)
Email: ietf@justin.richer.org Email: ietf@justin.richer.org
 End of changes. 21 change blocks. 
60 lines changed or deleted 131 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/