draft-ietf-radext-crypto-agility-requirements-02.txt   draft-ietf-radext-crypto-agility-requirements-03.txt 
Network Working Group D. Nelson Network Working Group D. Nelson
Internet-Draft Elbrys Networks, Inc. Internet-Draft Elbrys Networks, Inc.
Intended status: Informational March 3, 2011 Intended status: Informational March 3, 2011
Expires: September 3, 2011 Expires: September 3, 2011
Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS)
draft-ietf-radext-crypto-agility-requirements-02.txt draft-ietf-radext-crypto-agility-requirements-03.txt
Abstract Abstract
This memo describes the requirements for a crypto-agility solution This memo describes the requirements for a crypto-agility solution
for Remote Authentication Dial-In User Service (RADIUS). for Remote Authentication Dial-In User Service (RADIUS).
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with
provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 3, 2011. This Internet-Draft will expire on September 3, 2011.
Requirements Language Requirements Language
skipping to change at page 2, line 12 skipping to change at page 2, line 12
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with
to this document. Code Components extracted from this document must respect to this document. Code Components extracted from this
include Simplified BSD License text as described in Section 4.e of document must include Simplified BSD License text as described in
the Trust Legal Provisions and are provided without warranty as Section 4.e of the Trust Legal Provisions and are provided without
described in the Simplified BSD License. warranty as described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. General . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. The Charge . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. The Charge . . . . . . . . . . . . . . . . . . . . . . . . 3
2. A Working Definition of Crypto-Agility . . . . . . . . . . . . 3 2. A Working Definition of Crypto-Agility . . . . . . . . . . . . 3
3. The Current State of RADIUS Encryption . . . . . . . . . . . . 4 3. The Current State of RADIUS Security . . . . . . . . . . . . . 4
4. The Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 4. The Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Overall Solution Approach . . . . . . . . . . . . . . . . . 4 4.1. Overall Solution Approach . . . . . . . . . . . . . . . . . 4
4.2. Security Services . . . . . . . . . . . . . . . . . . . . . 4 4.2. Security Services . . . . . . . . . . . . . . . . . . . . . 4
4.3. Backwards Compatibility . . . . . . . . . . . . . . . . . . 5 4.3. Backwards Compatibility . . . . . . . . . . . . . . . . . . 6
4.4. Interoperability and Change Control . . . . . . . . . . . . 6 4.4. Interoperability and Change Control . . . . . . . . . . . . 6
4.5. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 6 4.5. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . 6
4.6. Applicability of Automated Key Management Requirements . . 6 4.6. Applicability of Automated Key Management Requirements . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. Informative References . . . . . . . . . . . . . . . . . . . . 7 8. Informative References . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
1.1. General 1.1. General
This memo describes the requirements for a crypto-agility solution This memo describes the requirements for a crypto-agility solution
for Remote Authentication Dial-In User Service (RADIUS). This memo, for Remote Authentication Dial-In User Service (RADIUS). This memo,
when approved, reflects the consensus of the RADIUS Extensions when approved, reflects the consensus of the RADIUS Extensions
Working Group of the IETF (RADEXT) as to the features, properties and Working Group of the IETF (RADEXT) as to the features, properties and
limitations of the crypto-agility work item for RADIUS. It also limitations of the crypto-agility work item for RADIUS. It also
skipping to change at page 3, line 37 skipping to change at page 3, line 37
Security Area Directorate to undertake the action item to prepare a Security Area Directorate to undertake the action item to prepare a
formal description of a crypto-agility work item, and corresponding formal description of a crypto-agility work item, and corresponding
milestones in the RADEXT Charter. After consultation with one of the milestones in the RADEXT Charter. After consultation with one of the
Security Area Directors, Russ Housley, text was initially proposed on Security Area Directors, Russ Housley, text was initially proposed on
the RADEXT WG mailing list on October 26, 2006. That text reads as the RADEXT WG mailing list on October 26, 2006. That text reads as
follows: follows:
The RADEXT WG will review the security requirements for crypto- The RADEXT WG will review the security requirements for crypto-
agility in IETF protocols, and identify the deficiencies of the agility in IETF protocols, and identify the deficiencies of the
existing RADIUS protocol specifications against these requirements. existing RADIUS protocol specifications against these requirements.
Specific attention will be paid to RFC 4962. Specific attention will be paid to RFC 4962 [RFC4962].
The RADEXT WG will propose one or more Internet Drafts to remediate The RADEXT WG will propose one or more Internet Drafts to remediate
any identified deficiencies in the crypto-agility properties of the any identified deficiencies in the crypto-agility properties of the
RADIUS protocol. The known deficiencies include the issue of RADIUS protocol. The known deficiencies include the issue of
negotiation of substitute algorithms for the message digest negotiation of substitute algorithms for the message digest
functions, the key-wrap functions, and the password-hiding function. functions, the key-wrap functions, and the password-hiding function.
Additionally, at least one mandatory to implement algorithm will be Additionally, at least one mandatory to implement algorithm will be
defined in each of these areas, as required. defined in each of these areas, as required.
2. A Working Definition of Crypto-Agility 2. A Working Definition of Crypto-Agility
skipping to change at page 4, line 13 skipping to change at page 4, line 13
a protocol to adapt to evolving cryptography and security a protocol to adapt to evolving cryptography and security
requirements. This may include the provision of a modular mechanism requirements. This may include the provision of a modular mechanism
to allow cryptographic algorithms to be updated without substantial to allow cryptographic algorithms to be updated without substantial
disruption to fielded implementations. It may provide for the disruption to fielded implementations. It may provide for the
dynamic negotiation and installation of cryptographic algorithms dynamic negotiation and installation of cryptographic algorithms
within protocol implementations (think of Dynamic-Link Libraries within protocol implementations (think of Dynamic-Link Libraries
(DLL)). (DLL)).
In the specific context of the RADIUS protocol and RADIUS In the specific context of the RADIUS protocol and RADIUS
implementations, crypto-agility may be better defined as the ability implementations, crypto-agility may be better defined as the ability
of RADIUS implementations to negotiate cryptographic algorithms for of RADIUS implementations to automatically negotiate cryptographic
use in RADIUS exchanges, including the cryptographic algorithms used algorithms for use in RADIUS exchanges, including the algorithms
to protect RADIUS packets and to hide RADIUS Attributes. This used to protect RADIUS packets and to hide RADIUS Attributes.
capability covers all RADIUS message types: Access-Request/Response, This capability covers all RADIUS message types:
Accounting-Request/Response, and CoA/Disconnect-Request/Response. Access-Request/Response, Accounting-Request/Response and
and CoA/Disconnect-Request/Response.
3. The Current State of RADIUS Encryption 3. The Current State of RADIUS Security
RADIUS packets, as defined in RFC 2865, are protected by an MD5-baed RADIUS packets, as defined in [RFC2865], are protected by an MD5
message integrity check (MIC), within the Authenticator field of message integrity check (MIC), within the Authenticator field of
RADIUS packets other than Access-Request. The Message-Authenticator RADIUS packets other than Access-Request. The Message-Authenticator
Attribute utilizes HMAC-MD5 to authenticate and integrity protect Attribute utilizes HMAC-MD5 to authenticate and integrity protect
RADIUS packets. Various RADIUS attributes support hidden values, RADIUS packets. Various RADIUS attributes support hidden values,
including: User-Password, Tunnel-Password, and various Vendor- including: User-Password, Tunnel-Password, and various Vendor-
Specific Attributes. Generally speaking, the hiding mechanism uses a Specific Attributes. Generally speaking, the hiding mechanism uses a
stream cipher based on a key stream from an MD5 digest. stream cipher based on a key stream from an MD5 digest.
Recent work on MD5 collisions does not immediately compromise any of Recent work on MD5 collisions does not immediately compromise any of
these methods, absent knowledge of the RADIUS shared secret. these methods, absent knowledge of the RADIUS shared secret.
However, the progress toward compromise of MD5's basic cryptographic However, the progress toward compromise of MD5's basic cryptographic
assumptions has resulted in the deprecation of MD5 usage in a variety assumptions has resulted in the deprecation of MD5 usage in a variety
of applications. of applications.
4. The Requirements 4. The Requirements
4.1. Overall Solution Approach 4.1. Overall Solution Approach
RADIUS crypto-agility solutions are not restricted to utilizing RADIUS crypto-agility solutions are not restricted to utilizing
technology described in existing RFCs. Since RADIUS over IPsec is technology described in existing RFCs. Since RADIUS over IPsec is
already described in RFC 3162 and RFC 3579, this technique is already already described in [RFC3162] and [RFC3579], this technique is
available to those who wish to use it. Therefore, it is expected already available to those who wish to use it. Therefore, it is
that proposals will utilize other techniques. expected that proposals will utilize other techniques.
4.2. Security Services 4.2. Security Services
Proposals MUST support the negotiation of cryptographic algorithms Proposals MUST support the negotiation of cryptographic algorithms
for per-packet integrity/authentication protection. Support for for per-packet integrity/authentication protection. Support for
confidentiality of entire RADIUS packets is OPTIONAL. However, confidentiality of entire RADIUS packets is OPTIONAL. However,
proposals MUST support the negotiation of algorithms for encryption proposals MUST support the negotiation of algorithms for encryption
(sometimes referred to as "hiding") of RADIUS attributes. If (sometimes referred to as "hiding") of RADIUS attributes. It is
possible, it is desirable for proposals to provide for the encryption RECOMMENDED for proposals to provide for the encryption
of existing attributes. This includes existing "hidden" attributes of existing attributes. This includes existing "hidden" attributes
as well as attributes (such as location attributes) that require as well as attributes (such as location attributes) that require
confidentiality. confidentiality.
Proposals MUST support replay protection. The existing mechanisms Proposals MUST support per-packet replay protection for all
for replay protection are considered adequate and should be RADIUS message types.
maintained.
Crypto-agility solutions MUST avoid security compromise, even in Crypto-agility solutions MUST avoid security compromise, even in
situations where the existing cryptographic algorithms utilized by situations where the existing cryptographic algorithms utilized by
RADIUS implementations are shown to be weak enough to provide little RADIUS implementations are shown to be weak enough to provide little
or no security (e.g. in event of compromise of the legacy RADIUS or no security (e.g. in event of compromise of the legacy RADIUS
shared secret). Included in this would be protection against bidding shared secret). Included in this would be protection against bidding
down attacks. down attacks. In analyzing the resilience of a crypto-agility
solution, it can be assumed that the RADIUS server can be configured
to require the use of new secure algorithms in the event of a
compromise of existing cryptographic algorithms or the legacy RADIUS
shared secret.
Crypto-agility solutions MUST specify mandatory-to-implement Crypto-agility solutions MUST specify mandatory-to-implement
algorithms for each defined mechanism. algorithms for each defined mechanism.
In addition to the above goals, [RFC4962] Section 2 describes
additional security requirements, which translate into the
following requirements for RADIUS crypto-agility solutions:
Strong, fresh session keys.
RADIUS crypto-agility solutions are REQUIRED to generate fresh
session keys for use between the RADIUS client and server.
In order to prevent the disclosure of one session key from
aiding an attacker in discovering other session keys, RADIUS
crypto-agility solutions are RECOMMENDED to support Perfect
Forward Secrecy (PFS) with respect to session keys negotiated
between the RADIUS client and server.
Limit key scope.
In order to enable a NAS and RADIUS server to transmit keying
material directly, it is RECOMMENDED that a RADIUS crypto-
agility solution be compatible with NAI-based Dynamic Peer
Discovery [RADYN] as well as that it support the use of public
key credentials for authentication between the NAS and RADIUS
server. For compatibility with existing operations, RADIUS
crypto-agility solutions SHOULD also support pre-shared key
credentials.
Prevent the Domino effect.
In order to prevent the domino effect, RADIUS crypto-agility
solutions MUST enable each RADIUS client and server pair to
authenticate utilizing unique credentials.
4.3. Backwards Compatibility 4.3. Backwards Compatibility
Solutions to the problem MUST demonstrate backward compatibility with Solutions to the problem MUST demonstrate backward compatibility with
existing RADIUS implementations. That is, a crypto-agility solution existing RADIUS implementations. That is, an implementation that
needs to be able to send packets that a legacy RADIUS client or supports both the crypto-agility solution and legacy mechanisms MUST
server will receive and process successfully. Similarly, a crypto- be able to talk with legacy RADIUS clients and servers (using the
agility solution needs to be capable of receiving and processing legacy mechanisms). Acceptable solutions to determining which set of
packets from a legacy RADIUS client or server. mechanisms is used (with a particular peer) include some kind of
negotiation, and manual configuration.
Proposals MUST NOT introduce new capabilities negotation features Proposals MUST NOT introduce new capabilities negotation features
into the RADIUS protocol, but rather MUST use the existing into the RADIUS protocol, but rather MUST use the existing
mechanisms. Included in such negotiation techniques are "hint and mechanisms. Included in such negotiation techniques are "hint and
accept" and "hint and reject" mechanisms, where the NAS (RADIUS accept" and "hint and reject" mechanisms, where the NAS (RADIUS
client) provides a list of supported algorithms and the RADIUS server client) provides a list of supported algorithms and the RADIUS server
selects one. selects one.
Crypto-agility solutions SHOULD NOT require changes to the RADIUS Crypto-agility solutions SHOULD NOT require changes to the RADIUS
operational model, such as the introduction of new commands or operational model as defined in "RADIUS Design Guidelines" [RFC6158]
maintenance of [additional] state on the RADIUS server. Similarly, a Section 3.1 and Appendix A.4. Similarly, a proposal SHOULD focus on
proposal SHOULD focus on the crypto-agility problem and nothing else. the crypto-agility problem and nothing else. For example, proposals
For example, proposals SHOULD NOT require new attribute formats or SHOULD NOT require new attribute formats and SHOULD be compatible
include definition of new RADIUS services. with the guidance provided in [RFC6158] Section 2.3.
4.4. Interoperability and Change Control 4.4. Interoperability and Change Control
Proposals MUST indicate a willingness to cede change control to the Proposals MUST indicate a willingness to cede change control to the
IETF. IETF.
Crypto-agility solutions MUST be interoperable between independent Crypto-agility solutions MUST be interoperable between independent
implementations based purely on the information provided in the implementations based purely on the information provided in the
specification. specification.
4.5. Scope of Work 4.5. Scope of Work
Crypto-agility solutions MUST apply to all RADIUS packet types, Crypto-agility solutions MUST apply to all RADIUS packet types,
including Access-Request, Access-Challenge, Access-Reject, Access- including Access-Request, Access-Challenge, Access-Reject, Access-
Accept, Accounting-Request, Accounting-Response, and CoA/Disconnect Accept, Accounting-Request, Accounting-Response, and CoA/Disconnect
messages. messages.
Proposals MUST include a Diameter compatibility section, although it Since it is expected that the work will occur purely within RADIUS
is expected that the work will occur purely within RADIUS or in the or in the transport, message data exchanged with Diameter SHOULD NOT
transport, and therefore does not affect message data that is be affected.
exchanged with Diameter.
Proposals MUST discuss any inherent assumptions about, or limitations Proposals MUST discuss any inherent assumptions about, or limitations
on, client/server operations or deployment and SHOULD provide on, client/server operations or deployment and SHOULD provide
recommendations for transition of deployments from legacy RADIUS to recommendations for transition of deployments from legacy RADIUS to
crypto-agile RADIUS. Issues regarding ciper-suite negotiation, crypto-agile RADIUS. Issues regarding ciper-suite negotiation,
legacy interoperability and the potential for biding down attacks, legacy interoperability and the potential for biding down attacks,
SHOULD be among these discussions. SHOULD be among these discussions.
4.6. Applicability of Automated Key Management Requirements 4.6. Applicability of Automated Key Management Requirements
[RFC4107] provides guidelines for when automated key management is [RFC4107] provides guidelines for when automated key management is
necessary. At the IETF-70 meeting, and leading up to that meeting, necessary. At the IETF-70 meeting, and leading up to that meeting,
the RADEXT WG debated whether or not RFC 4107 would require a RADIUS the RADEXT WG debated whether or not RFC 4107 would require a RADIUS
Crypto-Agility solution to feature Automated Key Management (AKM). Crypto-Agility solution to feature Automated Key Management (AKM).
The working group determined that AKM was not inherently required for The working group determined that AKM was not inherently required for
RADIUS based on the following points: RADIUS based on the following points:
o RFC 4107 requires AKM for protocols that involve O(n^2) keys. o RFC 4107 requires AKM for protocols that involve O(n^2) keys.
This does not apply to RADIUS deployments, which require O(n) keys This does not apply to RADIUS deployments, which require O(n) keys
o Requirements for session key freshness can be met without AKM,
for example, by utilizing a pre-shared key along with an exchange
of nonces.
o RADIUS does not require the encryption of large amounts of data in o RADIUS does not require the encryption of large amounts of data in
a short time a short time
o Organizations already have operational practices to manage o Organizations already have operational practices to manage
existing RADIUS shared secrets to address key changes required existing RADIUS shared secrets to address key changes required
through personnel changes as a result of personnel changes
o The crypto-agility solution can avoid use cryptographic modes of o The crypto-agility solution can avoid use cryptographic modes of
operation such as a counter mode cipher that require frequent key operation such as a counter mode cipher that require frequent key
changes changes
Automated key management is required for RADIUS crypto agility However, the same time, it is recognized that features recommended
solutions that use cryptographic modes of operation that require in Section 4.2 such as support for PFS and direct transport of keys
frequent key changes. between a NAS and RADIUS server, can only be provided by a solution
supporting AKM. As a result, support for Automated Key Management
is RECOMMENDED within a RADIUS crypto-agility solution.
Also, automated key management is REQUIRED for RADIUS crypto
agility solutions that use cryptographic modes of operation that
require frequent key changes.
5. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
6. Security Considerations 6. Security Considerations
This specification describes the requirements for new cryptographic This specification describes the requirements for new cryptographic
protection mechanisms, including the modular selection of algorithms protection mechanisms, including the modular selection of algorithms
and modes. Therefore, the subject matter of this memo is all about and modes. Therefore, the subject matter of this memo is all about
security. security.
7. Acknowledgements 7. Acknowledgements
Thanks to all the reviewers and contributors, inclding Bernard Aboba, Thanks to all the reviewers and contributors, inclding Bernard Aboba,
Joe Salowey and Glen Zorn. Joe Salowey and Glen Zorn.
8. Informative References 8. Informative References
[RADYN] Winter, S. and M. McCauley, "NAI-based Dynamic Peer
Discovery for RADIUS over TLS and DTLS", work in
progress, March 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001. RFC 3162, August 2001.
skipping to change at page 8, line 7 skipping to change at page 8, line 48
Dial In User Service) Support For Extensible Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003. Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005. Key Management", BCP 107, RFC 4107, June 2005.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management", Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007. BCP 132, RFC 4962, July 2007.
[RFC6158] DeKok, A., "RADIUS Design Guidelines", BCP X, RFC 6158,
March 2011.
Author's Address Author's Address
David B. Nelson David B. Nelson
Elbrys Networks, Inc. Elbrys Networks, Inc.
75 Rochester Avenue, Unit 3 282 Corporate Drive, Unit 1
Portsmouth, NH 03801 Portsmouth, NH 03801
USA USA
Email: d.b.nelson@comcast.net Email: d.b.nelson@comcast.net
 End of changes. 26 change blocks. 
57 lines changed or deleted 118 lines changed or added

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