draft-ietf-sipbrandy-osrtp-09.txt | draft-ietf-sipbrandy-osrtp-10.txt | |||
---|---|---|---|---|
SIPBRANDY Working Group A. Johnston | SIPBRANDY Working Group A. Johnston | |||
Internet-Draft Villanova University | Internet-Draft Villanova University | |||
Intended status: Informational B. Aboba | Intended status: Informational B. Aboba | |||
Expires: November 2, 2019 Microsoft | Expires: December 19, 2019 Microsoft | |||
A. Hutton | A. Hutton | |||
Atos | Atos | |||
R. Jesske | R. Jesske | |||
Deutsche Telekom | Deutsche Telekom | |||
T. Stach | T. Stach | |||
Unaffiliated | Unaffiliated | |||
May 1, 2019 | June 17, 2019 | |||
An Opportunistic Approach for Secure Real-time Transport Protocol | An Opportunistic Approach for Secure Real-time Transport Protocol | |||
(OSRTP) | (OSRTP) | |||
draft-ietf-sipbrandy-osrtp-09 | draft-ietf-sipbrandy-osrtp-10 | |||
Abstract | Abstract | |||
Opportunistic Secure Real-time Transport Protocol (OSRTP) is an | Opportunistic Secure Real-time Transport Protocol (OSRTP) is an | |||
implementation of the Opportunistic Security mechanism, as defined in | implementation of the Opportunistic Security mechanism, as defined in | |||
RFC 7435, applied to Real-time Transport Protocol (RTP). OSRTP | RFC 7435, applied to the Real-time Transport Protocol (RTP). OSRTP | |||
allows encrypted media to be used in environments where support for | allows encrypted media to be used in environments where support for | |||
encryption is not known in advance, and not required. OSRTP does not | encryption is not known in advance, and not required. OSRTP does not | |||
require SDP extensions or features and is fully backwards compatible | require Session Description Protocol (SDP) extensions or features and | |||
with existing implementations using encrypted and authenticated media | is fully backwards compatible with existing implementations using | |||
and implementations that do not encrypt or authenticate media | encrypted and authenticated media and implementations that do not | |||
packets. OSRTP is not specific to any key management technique for | encrypt or authenticate media packets. OSRTP is not specific to any | |||
SRTP. OSRTP is a transitional approach useful for migrating existing | key management technique for Secure RTP (SRTP). OSRTP is a | |||
deployments of real-time communications to a fully encrypted and | transitional approach useful for migrating existing deployments of | |||
authenticated state. | real-time communications to a fully encrypted and authenticated | |||
state. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | 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). 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 https://datatracker.ietf.org/drafts/current/. | Drafts is at https://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 December 19, 2019. | ||||
This Internet-Draft will expire on November 2, 2019. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 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 | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://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 32 ¶ | skipping to change at page 2, line 33 ¶ | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Applicability Statement . . . . . . . . . . . . . . . . . 3 | 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 3 | |||
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 | 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 | |||
3. SDP Offer/Answer Considerations . . . . . . . . . . . . . . . 3 | 3. SDP Offer/Answer Considerations . . . . . . . . . . . . . . . 3 | |||
3.1. Generating the Initial OSRTP Offer . . . . . . . . . . . 4 | 3.1. Generating the Initial OSRTP Offer . . . . . . . . . . . 4 | |||
3.2. Generating the Answer . . . . . . . . . . . . . . . . . . 4 | 3.2. Generating the Answer . . . . . . . . . . . . . . . . . . 4 | |||
3.3. Offerer Processing the Answer . . . . . . . . . . . . . . 4 | 3.3. Offerer Processing the Answer . . . . . . . . . . . . . . 4 | |||
3.4. Modifying the Session . . . . . . . . . . . . . . . . . . 5 | 3.4. Modifying the Session . . . . . . . . . . . . . . . . . . 5 | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | |||
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 | 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 | |||
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 | 7.2. Informative References . . . . . . . . . . . . . . . . . 7 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 8 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 | ||||
1. Introduction | 1. Introduction | |||
Opportunistic Security [RFC7435] (OS) is an approach to security that | Opportunistic Security [RFC7435] (OS) is an approach to security that | |||
defines a third mode for security between "cleartext" and | defines a third mode for security between "cleartext" and | |||
"comprehensive protection" that allows encryption and authentication | "comprehensive protection" that allows encryption and authentication | |||
of media to be used if supported but will not result in failures if | of media to be used if supported but will not result in failures if | |||
it is not supported. In terms of secure media, cleartext is RTP | it is not supported. In the context of the transport of secure media | |||
[RFC3550] media which is negotiated with the RTP/AVP (Audio Video | streams using RTP and is secured derivatives, cleartext is | |||
Profile) [RFC3551] or the RTP/AVPF profile [RFC4585]. Comprehensive | represented by an RTP [RFC3550] media stream which is negotiated with | |||
protection is Secure RTP [RFC3711], negotiated with a secure profile, | the RTP/AVP (Audio Video Profile) [RFC3551] or the RTP/AVPF profile | |||
such as SAVP or SAVPF [RFC5124]. OSRTP allows SRTP to be negotiated | [RFC4585], whereas, comprehensive protection is represented by a | |||
with the RTP/AVP profile, with fallback to RTP if SRTP is not | Secure RTP [RFC3711] stream, negotiated with a secure profile, such | |||
supported. | as SAVP or SAVPF [RFC5124]. OSRTP allows SRTP to be negotiated with | |||
the RTP/AVP profile, with fallback to RTP if SRTP is not supported. | ||||
There have been some extensions to SDP to allow profiles to be | There have been some extensions to SDP to allow profiles to be | |||
negotiated such as SDP Capabilities Negotiation (capneg) [RFC5939] . | negotiated such as SDP Capabilities Negotiation (capneg) [RFC5939]. | |||
However, these approaches are complex and have very limited | However, these approaches are complex and have very limited | |||
deployment in communication systems. Other key management protocols | deployment in communication systems. Other key management protocols | |||
for SRTP have been developed which by design use OS, such as ZRTP | for SRTP have been developed which by design use OS, such as ZRTP | |||
[RFC6189]. This approach for OSRTP is based on | [RFC6189]. This approach for OSRTP is based on | |||
[I-D.kaplan-mmusic-best-effort-srtp] where it was called "best effort | [I-D.kaplan-mmusic-best-effort-srtp] where it was called "best effort | |||
SRTP". [I-D.kaplan-mmusic-best-effort-srtp] has a full discussion of | SRTP". [I-D.kaplan-mmusic-best-effort-srtp] has a full discussion of | |||
the motivation and requirements for opportunistic secure media. | the motivation and requirements for opportunistic secure media. | |||
OSRTP uses the presence of SRTP keying-related attributes in an SDP | OSRTP uses the presence of SRTP keying-related attributes in an SDP | |||
offer to indicate support for opportunistic secure media. The | offer to indicate support for opportunistic secure media. The | |||
skipping to change at page 3, line 37 ¶ | skipping to change at page 3, line 39 ¶ | |||
unencrypted communication (RTP) to fully encrypted communication | unencrypted communication (RTP) to fully encrypted communication | |||
(SRTP). It is only to be used in existing deployments which are | (SRTP). It is only to be used in existing deployments which are | |||
attempting to transition to fully secure communications. New | attempting to transition to fully secure communications. New | |||
applications and new deployments will not use OSRTP. | applications and new deployments will not use OSRTP. | |||
2. Requirements Language | 2. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
appear in all capitals, as shown here. | capitals, as shown here. | |||
3. SDP Offer/Answer Considerations | 3. SDP Offer/Answer Considerations | |||
This section defines the SDP offer/answer considerations for | This section defines the SDP offer/answer considerations for | |||
opportunistic security. | opportunistic security. | |||
The procedures are for a specific m- section describing RTP-based | The procedures are for a specific m= section describing RTP-based | |||
media. If an SDP offer or answer contains multiple such m- sections, | media. If an SDP offer or answer contains multiple such m= sections, | |||
the procedures are applied to each m- section individually. | the procedures are applied to each m= section individually. | |||
"Initial OSRTP offer" refers to the offer in which oportunistic | "Initial OSRTP offer" refers to the offer in which oportunistic | |||
security is offered for an m- section for the first time within an | security is offered for an m= section for the first time within an | |||
SDP session. | SDP session. | |||
It is important to note that OSRTP makes no changes, and has no | It is important to note that OSRTP makes no changes, and has no | |||
effect on media sessions in which the offer contains a secure profile | effect on media sessions in which the offer contains a secure profile | |||
of RTP, such as SAVP or SAVPF. As discussed in [RFC7435], that is | of RTP, such as SAVP or SAVPF. As discussed in [RFC7435], that is | |||
the "comprehensive protection" for media mode. | the "comprehensive protection" for media mode. | |||
3.1. Generating the Initial OSRTP Offer | 3.1. Generating the Initial OSRTP Offer | |||
To indicate support for OSRTP in an SDP offer, the offerer uses the | To indicate support for OSRTP in an SDP offer, the offerer uses the | |||
skipping to change at page 5, line 12 ¶ | skipping to change at page 5, line 12 ¶ | |||
this session. If the SRTP key management fails, the media session | this session. If the SRTP key management fails, the media session | |||
MUST fail. | MUST fail. | |||
3.4. Modifying the Session | 3.4. Modifying the Session | |||
When an offerer generates a subsequent SDP offer it should do so | When an offerer generates a subsequent SDP offer it should do so | |||
following the principles of [RFC6337] meaning that the decision to | following the principles of [RFC6337] meaning that the decision to | |||
create the new SDP offer should not be influenced by what was | create the new SDP offer should not be influenced by what was | |||
previously negotiated. For example if a previous OSRTP offer did not | previously negotiated. For example if a previous OSRTP offer did not | |||
result in SRTP being established the offerer may try again and | result in SRTP being established the offerer may try again and | |||
generate a new OSRTP offer as specified in section [3.1]. | generate a new OSRTP offer as specified in section 3.1. | |||
4. Security Considerations | 4. Security Considerations | |||
The security considerations of [RFC7435] apply to OSRTP, as well as | The security considerations of [RFC4568] apply to OSRTP, as well as | |||
the security considerations of the particular SRTP key agreement | the security considerations of the particular SRTP key agreement | |||
approach used. However, the authentication requirements of a | approach used. However, the authentication requirements of a | |||
particular SRTP key agreement approach are relaxed when that key | particular SRTP key agreement approach are relaxed when that key | |||
agreement is used with OSRTP, which is consistent with the | agreement is used with OSRTP, which is consistent with the | |||
Opportunistic Security approach described [RFC7435]. For example: | Opportunistic Security approach described [RFC7435]. For example: | |||
For DTLS-SRTP key agreement [RFC5763], an authenticated signaling | For DTLS-SRTP key agreement [RFC5763], an authenticated signaling | |||
channel does not need to be used with OSRTP if it is not | channel does not need to be used with OSRTP if it is not | |||
available. | available. | |||
For SDP Security Descriptions key agreement [RFC4568], an | For SDP Security Descriptions key agreement [RFC4568], an | |||
authenticated signaling channel does not need to be used with | authenticated signaling channel does not need to be used with | |||
OSRTP if it is not available, although an encrypted signaling | OSRTP if it is not available, although an encrypted signaling | |||
channel must still be used. | channel MUST still be used. | |||
For ZRTP key agreement [RFC6189], the security considerations are | For ZRTP key agreement [RFC6189], the security considerations are | |||
unchanged, since ZRTP does not rely on the security of the | unchanged, since ZRTP does not rely on the security of the | |||
signaling channel. | signaling channel. | |||
While OSRTP does not require authentication of the key-agreement | While OSRTP does not require authentication of the key-agreement | |||
mechanism, it does need to avoid exposing SRTP keys to eavesdroppers, | mechanism, it does need to avoid exposing SRTP keys to eavesdroppers, | |||
since this could enable passive attacks against SRTP. Section 8.3 of | since this could enable passive attacks against SRTP. Section 8.3 of | |||
[RFC7435] requires that any messages that contain SRTP keys be | [RFC4568] requires that any messages that contain SRTP keys be | |||
encrypted, and further says that encryption "SHOULD" provide end-to- | encrypted, and further says that encryption "SHOULD" provide end-to- | |||
end confidentiality protection if intermediaries that could inspect | end confidentiality protection if intermediaries that could inspect | |||
the SDP message are present. At the time of this writing, it is | the SDP message are present. At the time of this writing, it is | |||
understood that the [RFC7435] requirement for end-to-end | understood that the [RFC4568] requirement for end-to-end | |||
confidentiality protection is commonly ignored. Therefore, if OSRTP | confidentiality protection is commonly ignored. Therefore, if OSRTP | |||
is used with SDP Security Descriptions, any such intermediaries | is used with SDP Security Descriptions, any such intermediaries | |||
(e.g., SIP proxies) must be assumed to have access to the SRTP keys. | (e.g., SIP proxies) must be assumed to have access to the SRTP keys. | |||
As discussed in [RFC7435], OSRTP is used in cases where support for | As discussed in [RFC7435], OSRTP is used in cases where support for | |||
encryption by the other party is not known in advance, and not | encryption by the other party is not known in advance, and not | |||
required. For cases where it is known that the other party supports | required. For cases where it is known that the other party supports | |||
SRTP or SRTP needs to be used, OSRTP MUST NOT be used. Instead, a | SRTP or SRTP needs to be used, OSRTP MUST NOT be used. Instead, a | |||
secure profile of RTP is used in the offer. | secure profile of RTP is used in the offer. | |||
5. IANA Considerations | 5. IANA Considerations | |||
This document has no actions for IANA. | This document has no actions for IANA. | |||
6. Implementation Status | 6. Acknowledgements | |||
Note to RFC Editor: Please remove this entire section prior to | ||||
publication, including the reference to [RFC6982]. | ||||
This section records the status of known implementations of the | ||||
protocol defined by this specification at the time of posting of this | ||||
Internet-Draft, and is based on a proposal described in [RFC6982]. | ||||
The description of implementations in this section is intended to | ||||
assist the IETF in its decision processes in progressing drafts to | ||||
RFCs. Please note that the listing of any individual implementation | ||||
here does not imply endorsement by the IETF. Furthermore, no effort | ||||
has been spent to verify the information presented here that was | ||||
supplied by IETF contributors. This is not intended as, and must not | ||||
be construed to be, a catalog of available implementations or their | ||||
features. Readers are advised to note that other implementations may | ||||
exist. | ||||
According to [RFC6982], "this will allow reviewers and working groups | ||||
to assign due consideration to documents that have the benefit of | ||||
running code, which may serve as evidence of valuable experimentation | ||||
and feedback that have made the implemented protocols more mature. | ||||
It is up to the individual working groups to use this information as | ||||
they see fit". | ||||
There are implementations of [I-D.kaplan-mmusic-best-effort-srtp] in | ||||
deployed products by Microsoft and Unify. The IMTC "Best Practices | ||||
for SIP Security" document [IMTC-SIP] recommends this approach. The | ||||
SIP Forum planned to include support in the SIPconnect 2.0 SIP | ||||
trunking recommendation [SIPCONNECT]. There are many deployments of | ||||
ZRTP [RFC6189]. | ||||
7. Acknowledgements | ||||
This document is dedicated to our friend and colleague Francois Audet | This document is dedicated to our friend and colleague Francois Audet | |||
who is greatly missed in our community. His work on improving | who is greatly missed in our community. His work on improving | |||
security in SIP and RTP provided the foundation for this work. | security in SIP and RTP provided the foundation for this work. | |||
Thanks to Eric Rescorla, Martin Thomson, Christer Holmberg, and | Thanks to Eric Rescorla, Martin Thomson, Christer Holmberg, and | |||
Richard Barnes for their comments. | Richard Barnes for their comments. | |||
8. References | 7. References | |||
8.1. Normative References | 7.1. Normative References | |||
[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, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model | [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model | |||
with Session Description Protocol (SDP)", RFC 3264, | with Session Description Protocol (SDP)", RFC 3264, | |||
DOI 10.17487/RFC3264, June 2002, | DOI 10.17487/RFC3264, June 2002, | |||
<https://www.rfc-editor.org/info/rfc3264>. | <https://www.rfc-editor.org/info/rfc3264>. | |||
skipping to change at page 8, line 24 ¶ | skipping to change at page 7, line 35 ¶ | |||
<https://www.rfc-editor.org/info/rfc6189>. | <https://www.rfc-editor.org/info/rfc6189>. | |||
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection | [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection | |||
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, | Most of the Time", RFC 7435, DOI 10.17487/RFC7435, | |||
December 2014, <https://www.rfc-editor.org/info/rfc7435>. | December 2014, <https://www.rfc-editor.org/info/rfc7435>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
8.2. Informative References | 7.2. Informative References | |||
[I-D.kaplan-mmusic-best-effort-srtp] | [I-D.kaplan-mmusic-best-effort-srtp] | |||
Audet, F. and H. Kaplan, "Session Description Protocol | Audet, F. and H. Kaplan, "Session Description Protocol | |||
(SDP) Offer/Answer Negotiation For Best-Effort Secure | (SDP) Offer/Answer Negotiation For Best-Effort Secure | |||
Real-Time Transport Protocol", draft-kaplan-mmusic-best- | Real-Time Transport Protocol", draft-kaplan-mmusic-best- | |||
effort-srtp-01 (work in progress), October 2006. | effort-srtp-01 (work in progress), October 2006. | |||
[IMTC-SIP] | ||||
Group, I. S. P. A., "Best Practices for SIP Security", | ||||
IMTC SIP Parity | ||||
Group http://www.imtc.org/uc/sip-parity-activity-group/, | ||||
2011, <http://www.imtc.org>. | ||||
[RFC5939] Andreasen, F., "Session Description Protocol (SDP) | [RFC5939] Andreasen, F., "Session Description Protocol (SDP) | |||
Capability Negotiation", RFC 5939, DOI 10.17487/RFC5939, | Capability Negotiation", RFC 5939, DOI 10.17487/RFC5939, | |||
September 2010, <https://www.rfc-editor.org/info/rfc5939>. | September 2010, <https://www.rfc-editor.org/info/rfc5939>. | |||
[RFC6337] Okumura, S., Sawada, T., and P. Kyzivat, "Session | [RFC6337] Okumura, S., Sawada, T., and P. Kyzivat, "Session | |||
Initiation Protocol (SIP) Usage of the Offer/Answer | Initiation Protocol (SIP) Usage of the Offer/Answer | |||
Model", RFC 6337, DOI 10.17487/RFC6337, August 2011, | Model", RFC 6337, DOI 10.17487/RFC6337, August 2011, | |||
<https://www.rfc-editor.org/info/rfc6337>. | <https://www.rfc-editor.org/info/rfc6337>. | |||
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running | ||||
Code: The Implementation Status Section", RFC 6982, | ||||
DOI 10.17487/RFC6982, July 2013, | ||||
<https://www.rfc-editor.org/info/rfc6982>. | ||||
[SIPCONNECT] | ||||
Group, S. F. S. 2. T., "SIP-PBX / Service Provider | ||||
Interoperability SIPconnect 2.0 - Technical | ||||
Recommendation", SIP Forum http://www.sipforum.org/compone | ||||
nt/option,com_docman/task,doc_download/gid,838/ | ||||
Itemid,261/, 2017, <http://www.sipforum.org>. | ||||
Authors' Addresses | Authors' Addresses | |||
Alan Johnston | Alan Johnston | |||
Villanova University | Villanova University | |||
Villanova, PA | Villanova, PA | |||
USA | USA | |||
Email: alan.b.johnston@gmail.com | Email: alan.b.johnston@gmail.com | |||
Bernard Aboba | Bernard Aboba | |||
End of changes. 23 change blocks. | ||||
92 lines changed or deleted | 42 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |