draft-ietf-msec-policy-token-sec-04.txt   draft-ietf-msec-policy-token-sec-05.txt 
Internet Engineering Task Force Internet Engineering Task Force
INTERNET-DRAFT A Colegrove (SPARTA) INTERNET-DRAFT A Colegrove
H Harney (SPARTA) H Harney
draft-ietf-msec-policy-token-sec-04.txt SPARTA, Inc. draft-ietf-msec-policy-token-sec-05.txt SPARTA, Inc.
Expires: March 30, 2006 September 2005 Expires: June 16, 2006 December 2005
Group Security Policy Token v1 Group Security Policy Token v1
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 2, line ? skipping to change at page 2, line ?
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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
Abstract Abstract
The Group Security Policy Token is a structure used to The Group Security Policy Token is a structure used to
specify the security policy and configurable parameters for specify the security policy and configurable parameters
a cryptographic group, such as a secure multicast group. for a cryptographic group, such as a secure multicast
This document specifies the structure of such a token in group. Because the security of a group is comprised of
order to securely bind system-level security to protocols the totality of multiple security services, mechanisms, and
supporting the management of cryptographic groups. attributes throughout the communications infrastructure,
an authenticatable representation of the features that
must be supported throughout the system is needed to ensure
consistent security. This document specifies the structure
of such a token.
Contents Contents
1 Introduction 4 1 Introduction 5
2 Token Creation and Receipt 5 2 Token Creation and Receipt 6
3 The Policy Token 5 3 The Policy Token 6
3.1 Token Identifiers . . . . . . . . . . . . . . . . . . . . . 6 3.1 Token Identifiers . . . . . . . . . . . . . . . . . . . . . 7
3.2 Registration Policy . . . . . . . . . . . . . . . . . . . . 7 3.2 Registration Policy . . . . . . . . . . . . . . . . . . . . 8
3.3 Rekey Policy . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Rekey Policy . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Group Data Policy . . . . . . . . . . . . . . . . . . . . . 8 3.4 Group Data Policy . . . . . . . . . . . . . . . . . . . . . 9
4 Security Considerations 9 4 Security Considerations 10
5 IANA Considerations 9 5 IANA Considerations 10
6 References 10 6 References 11
6.1 Normative References . . . . . . . . . . . . . . . . . . . 10 6.1 Normative References . . . . . . . . . . . . . . . . . . . 11
6.2 Non-Normative References . . . . . . . . . . . . . . . . . 10 6.2 Non-Normative References . . . . . . . . . . . . . . . . . 11
7 Acknowledgments 11 7 Acknowledgments 12
A APPENDIX A -- Core Policy Token ASN.1 Module 12 A APPENDIX A -- Core Policy Token ASN.1 Module 13
B APPENDIX B -- GSAKMPv1 Base Policy 14 B APPENDIX B -- GSAKMPv1 Base Policy 15
B.1 GSAKMPv1 Registration Policy . . . . . . . . . . . . . . . 14 B.1 GSAKMPv1 Registration Policy . . . . . . . . . . . . . . . 15
B.1.1 Authorization . . . . . . . . . . . . . . . . . . . . . 14 B.1.1 Authorization . . . . . . . . . . . . . . . . . . . . . 15
B.1.2 AccessControl . . . . . . . . . . . . . . . . . . . . 16 B.1.2 AccessControl . . . . . . . . . . . . . . . . . . . . . 17
B.1.3 JoinMechanisms . . . . . . . . . . . . . . . . . . . . 16 B.1.3 JoinMechanisms . . . . . . . . . . . . . . . . . . . . 17
B.1.3.1 alaCarte . . . . . . . . . . . . . . . . . . . . 17 B.1.3.1 alaCarte . . . . . . . . . . . . . . . . . . . . 18
B.1.3.2 suite . . . . . . . . . . . . . . . . . . . . . 18 B.1.3.2 suite . . . . . . . . . . . . . . . . . . . . . . 19
B.1.4Transport . . . . . . . . . . . . . . . . . . . . . . . 19 B.1.4Transport . . . . . . . . . . . . . . . . . . . . . . . 20
B.2 GSAKMPv1 Registration ASN.1 Module . . . . . . . . . . . . 19 B.2 GSAKMPv1 Registration ASN.1 Module . . . . . . . . . . . . 20
B.3 GSAKMPv1 De-Registration Policy . . . . . . . . . . . . . . 22 B.3 GSAKMPv1 De-Registration Policy . . . . . . . . . . . . . . 23
B.4 GSAKMPv1 De-Registration ASN.1 Module . . . . . . . . . . . 23 B.4 GSAKMPv1 De-Registration ASN.1 Module . . . . . . . . . . . 24
B.5 GSAKMPv1 Rekey Policy . . . . . . . . . . . . . . . . . . . 23 B.5 GSAKMPv1 Rekey Policy . . . . . . . . . . . . . . . . . . . 24
B.5.1 Rekey Authorization . . . . . . . . . . . . . . . . . . 24 B.5.1 Rekey Authorization . . . . . . . . . . . . . . . . . . 25
B.5.2 Rekey Mechanisms . . . . . . . . . . . . . . . . . . . 24 B.5.2 Rekey Mechanisms . . . . . . . . . . . . . . . . . . . 25
B.5.3 Rekey Event Definition . . . . . . . . . . . . . . . . 25 B.5.3 Rekey Event Definition . . . . . . . . . . . . . . . . 26
B.5.4 Rekey Methods . . . . . . . . . . . . . . . . . . . . . 26 B.5.4Rekey Methods . . . . . . . . . . . . . . . . . . . . . 27
B.5.4.1 Rekey Method NONE . . . . . . . . . . . . . . . . 26 B.5.4.1 Rekey Method NONE . . . . . . . . . . . . . . . . 27
B.5.4.2 Rekey Method GSAKMP LKH . . . . . . . . . . . . . 26 B.5.4.2 Rekey Method GSAKMP LKH . . . . . . . . . . . . . 27
B.5.5 Rekey Interval . . . . . . . . . . . . . . . . . . . . 27 B.5.5 Rekey Interval . . . . . . . . . . . . . . . . . . . . 28
B.5.6 Rekey Reliability . . . . . . . . . . . . . . . . . . . 27 B.5.6 Rekey Reliability . . . . . . . . . . . . . . . . . . . 28
B.5.6.1 Rekey Reliability Mechanism None . . . . . . . . 27 B.5.6.1 Rekey Reliability Mechanism None . . . . . . . . 28
B.5.6.2 Rekey Reliability Mechanism Resend . . . . . . . 27 B.5.6.2 Rekey Reliability Mechanism Resend . . . . . . . 28
B.5.6.3 Rekey Reliability Mechanism Post . . . . . . . . 28 B.5.6.3 Rekey Reliability Mechanism Post . . . . . . . . 29
B.5.7 Distributed Operation Policy . . . . . . . . . . . . . 28 B.5.7 Distributed Operation Policy . . . . . . . . . . . . . 29
B.5.7.1 No Distributed Operation . . . . . . . . . . . . 28 B.5.7.1 No Distributed Operation . . . . . . . . . . . . 29
B.5.7.2 Autonomous Distributed Mode . . . . . . . . . . . 29 B.5.7.2 Autonomous Distributed Mode . . . . . . . . . . . 30
B.6 GSAKMPv1 Rekey Policy ASN.1 Module . . . . . . . . . . . . 29 B.6 GSAKMPv1 Rekey Policy ASN.1 Module . . . . . . . . . . . . 30
C APPENDIX C -- Data SA Policy 32 C APPENDIX C -- Data SA Policy 33
C.1 Generic Data Policy . . . . . . . . . . . . . . . . . . . . 32 C.1 Generic Data Policy . . . . . . . . . . . . . . . . . . . . 33
C.2 Generic Data Policy ASN.1 Module . . . . . . . . . . . . . 33 C.2 Generic Data Policy ASN.1 Module . . . . . . . . . . . . . 34
D APPENDIX D -- Change History (To Be Removed from RFC) 33 D APPENDIX D -- Change History (To Be Removed from RFC) 34
D.1 Changes from Group Policy Token v-00 to v-01, December 2004 33 D.1 Changes from Group Policy Token v-00 to v-01, December 2004 34
D.2 Changes from Group Policy Token v-01 to v-02, March 2005 . 34 D.2 Changes from Group Policy Token v-01 to v-02, March 2005 . 35
D.3 Changes from Group Policy Token v-02 to v-03, July 2005 . . 34 D.3 Changes from Group Policy Token v-02 to v-03, July 2005 . . 35
D.4 Changes from Group Policy Token v-03 to v-04, September 2005 34 D.4 Changes from Group Policy Token v-03 to v-04, September 2005 35
D.5 Changes from Group Policy Token v-04 to v-05, December 2005 35
Authors Addresses 35 Authors Addresses 36
Full Copyright Statement 35 Full Copyright Statement 36
IPR Considerations 35 IPR Considerations 36
1 Introduction 1 Introduction
The Multicast Group Security Architecture [RFC3740] defines the The Multicast Group Security Architecture [RFC3740] defines the
security infrastructure to support secure group communications. The security infrastructure to support secure group communications. The
Policy Token assumes this architecture in its definition. It defines Policy Token assumes this architecture in its definition. It defines
the enforceable security parameters for a Group Secure Association. the enforceable security parameters for a Group Secure Association.
The Policy Token is a verifiable data construct signed by the group The Policy Token is a verifiable data construct signed by the group
owner, the entity with the authorization to create security policy. owner, the entity with the authorization to create security policy.
The group controllers in a group will use the policy token to ensure The group controllers in a group will use the policy token to ensure
that the mechanisms used to secure the group are correct and to that the mechanisms used to secure the group are correct and to
enforce the access control rules for joining members. The group enforce the access control rules for joining members. The group
members, who may contribute data to the group or access data from the members, who may contribute data to the group or access data from the
group, will use the policy token to ensure that the group is owned by group, will use the policy token to ensure that the group is owned by
a trusted authority. Also, the members may want to verify that the a trusted authority. Also, the members may want to verify that the
access control rules are adequate to protect the data that member is access control rules are adequate to protect the data that the member
submitting to the group. is submitting to the group.
The Policy Token is specified in ASN.1 and is to be DER encoded. The Policy Token is specified in ASN.1 [X.208] and is to be DER
This specification ability allows the token to easily import group [X.660] encoded. This specification ability allows the token to
definitions that span different applications and environments. easily import group definitions that span different applications and
ASN.1 allows the token to specify branches that can be used by any environments. ASN.1 allows the token to specify branches that can
multicast security protocol. Any group can use this policy token be used by any multicast security protocol. Any group can use this
structure to specify the use of multiple protocols in securing the policy token structure to specify the use of multiple protocols in
group. securing the group.
Care was taken in this specification to provide a core level of token Care was taken in this specification to provide a core level of token
specificity that would allow ease of extensibility and flexibility specificity that would allow ease of extensibility and flexibility
in supporting mechanisms. This was done by using the following in supporting mechanisms. This was done by using the following
abstracted construct: abstracted construct:
Mechanism ::= SEQUENCE { Mechanism ::= SEQUENCE {
mechanismIdentifier OBJECT IDENTIFIER, mechanismIdentifier OBJECT IDENTIFIER,
mechanismParameters OCTET STRING mechanismParameters OCTET STRING
} }
skipping to change at page 5, line 17 skipping to change at page 6, line 17
At the time of group creation or whenever the policy of the group is At the time of group creation or whenever the policy of the group is
updated, the Group Owner will create a new policy token. updated, the Group Owner will create a new policy token.
To ensure authenticity of the specified policy, the Token MUST be To ensure authenticity of the specified policy, the Token MUST be
signed by the Group Owner. The signed token MUST be in accordance signed by the Group Owner. The signed token MUST be in accordance
with the CMS [RFC 3852] SignedData type. with the CMS [RFC 3852] SignedData type.
The content of the SignedData is the token itself. It is represented The content of the SignedData is the token itself. It is represented
with the ContentType object identifier of with the ContentType object identifier of
id-msec-token OBJECT IDENTIFIER ::= {TBD} id-ct-msec-token OBJECT IDENTIFIER ::= {TBD}
The CMS sid value of the SignerInfo MUST be that of the Group Owner. The CMS sid value of the SignerInfo, which identifies the public key
needed to validate the signature, MUST be that of the Group Owner.
The signedAttrs field MUST be present. In addition to the minimally The signedAttrs field MUST be present. In addition to the minimally
required fields of signedAttrs, the signing-time attribute MUST be required fields of signedAttrs, the signing-time attribute MUST be
PRESENT and MUST be specified as a GeneralizedTime value. present.
Upon receipt of a Policy Token, the recipient MUST check that Upon receipt of a Policy Token, the recipient MUST check that
- the Group Owner, as identified by the sid in the SignerInfo, is - the Group Owner, as identified by the sid in the SignerInfo, is
the expected entity the expected entity
- the signing-time value is more recent than the signing-time value - the signing-time value is more recent than the signing-time value
seen in a previously received Policy Token for that group, or the seen in a previously received Policy Token for that group, or the
Policy Token is the first token seen by the recipient for that Policy Token is the first token seen by the recipient for that
group. group.
- the processing of the signature succeeds in accordance with RFC - the processing of the signature successfully validates in
3852 accordance with RFC 3852
- the specified security and communication mechanisms (or at least - the specified security and communication mechanisms (or at least
one mechanism of each choice) are supported and are in compliance one mechanism of each choice) are supported and are in compliance
with the recipient's local policy. with the recipient's local policy.
3 The Policy Token 3 The Policy Token
The structure of the Policy Token is as follows: The structure of the Policy Token is as follows:
Token ::= SEQUENCE { Token ::= SEQUENCE {
skipping to change at page 7, line 9 skipping to change at page 8, line 9
3.1 Token Identifiers 3.1 Token Identifiers
tokenInfo explicitly identifies a version of the Policy Token for a tokenInfo explicitly identifies a version of the Policy Token for a
particular group. It is defined as particular group. It is defined as
TokenID ::= SEQUENCE { TokenID ::= SEQUENCE {
groupName OCTET STRING, groupName OCTET STRING,
edition INTEGER OPTIONAL edition INTEGER OPTIONAL
} }
groupName is the identifier of the group groupName is the identifier of the group and MUST be unique relative
to the Group Owner.
edition is an optional INTEGER indicating the sequence number of the edition is an optional INTEGER indicating the sequence number of the
PT. If edition is present, group entities MUST accept a PT only PT. If edition is present, group entities MUST accept a PT only
when the value is greater than the last value seen in a valid PT when the value is greater than the last value seen in a valid PT
for that group. for that group.
The type LifeDate is also defined to provide standard methods of The type LifeDate is also defined to provide standard methods of
indicating timestamps and intervals in the Tokens. indicating timestamps and intervals in the Tokens.
LifeDate ::= CHOICE { LifeDate ::= CHOICE {
gt [0] GeneralizedTime, gt GeneralizedTime,
utc [1] UTCTime, utc UTCTime,
interval [2] INTEGER interval INTEGER
} }
3.2 Registration Policy 3.2 Registration Policy
The registration SA is defined in the MSEC Architecture. During The registration SA is defined in the MSEC Architecture. During
registration, a prospective group member and the group controller registration, a prospective group member and the group controller
will interact to give the group member access to the keys and will interact to give the group member access to the keys and
information it needs to join the group and participate in the group information it needs to join the group and participate in the group
data SA. data SA.
skipping to change at page 8, line 5 skipping to change at page 9, line 5
GC/KS that it will no longer be participating in the data SA. GC/KS that it will no longer be participating in the data SA.
Registration ::= SEQUENCE { Registration ::= SEQUENCE {
register GroupMngmtProtocol, register GroupMngmtProtocol,
de-register GroupMngmtProtocol de-register GroupMngmtProtocol
} }
The protocol for registration and de-registration are each specified The protocol for registration and de-registration are each specified
as as
GroupMngmtProtocol ::= CHOICE { GroupMngmtProtocol ::= CHOICE {
none [0] NULL, none NULL,
supported [1] Protocol supported Protocol
} }
Protocol ::= SEQUENCE { Protocol ::= SEQUENCE {
protocol OBJECT IDENTIFIER, protocol OBJECT IDENTIFIER,
protocolInfo OCTET STRING protocolInfo OCTET STRING
} }
For example, register might be specified as the GSAKMP [HMCG] For example, register might be specified as the GSAKMP [HMCG]
registration protocol. The OBJECT IDENTIFIER TBS would be followed registration protocol. The OBJECT IDENTIFIER TBS would be followed
by the parameters used in GSAKMP registration as specified in by the parameters used in GSAKMP registration as specified in
skipping to change at page 9, line 30 skipping to change at page 10, line 30
Furthermore, while the Group Owner may list alternate mechanisms Furthermore, while the Group Owner may list alternate mechanisms
for various functions, the group is only as strong as the weakest for various functions, the group is only as strong as the weakest
accepted mechanisms. As such, the Group Owner is responsible for accepted mechanisms. As such, the Group Owner is responsible for
providing only acceptable security mechanisms. providing only acceptable security mechanisms.
5 IANA Considerations 5 IANA Considerations
The following object identifiers should be assigned: The following object identifiers should be assigned:
- id-msec-token OBJECT IDENTIFIER ::= TBD - id-ct-msec-token OBJECT IDENTIFIER ::= TBD
- id-securitySuiteOne OBJECT IDENTIFIER ::= TBD - id-securitySuiteOne OBJECT IDENTIFIER ::= TBD
- id-GSAKMPv1RegistrationProtocol OBJECT IDENTIFIER::= TBD - id-GSAKMPv1RegistrationProtocol OBJECT IDENTIFIER::= TBD
- id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= TBD - id-GSAKMPv1DeRegistrationProtocol OBJECT IDENTIFIER::= TBD
- id-GSAKMPv1Rekey OBJECT IDENTIFIER::= TBD - id-GSAKMPv1Rekey OBJECT IDENTIFIER::= TBD
- id-rekeyNone OBJECT IDENTIFIER ::= TBD - id-rekeyNone OBJECT IDENTIFIER ::= TBD
skipping to change at page 10, line 29 skipping to change at page 11, line 29
[HMCG] H. Harney, U. Meth, A. Colegrove, and G. Gross, "GSAKMP", [HMCG] H. Harney, U. Meth, A. Colegrove, and G. Gross, "GSAKMP",
draft-ietf-msec-gsakmp-sec-10.txt, RFC Editor Queue, May 2005. draft-ietf-msec-gsakmp-sec-10.txt, RFC Editor Queue, May 2005.
[RFC 3280] R. Housley, W. Polk, W. Ford, D. Solo, Internet X.509 [RFC 3280] R. Housley, W. Polk, W. Ford, D. Solo, Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation List Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile, RFC 3280, April 2002. (CRL) Profile, RFC 3280, April 2002.
[RFC 3852] R. Housley, Cryptographic Message Syntax, RFC 3825, July [RFC 3852] R. Housley, Cryptographic Message Syntax, RFC 3825, July
2004. 2004.
[X.208] Recommendation X.209, Specification of Abstract Syntax
Notation One (ASN.1), 1988.
[X.660] Recommendation X.660, Information Technology ASN.1 Encoding
Rules: Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER), and Distinguished Encoding Rules (DER), 1997.
6.2 Non-Normative References 6.2 Non-Normative References
[HCLM00] H. Harney, A. Colegrove, P. Lough, and U. Meth, "GSAKMP [HCLM00] H. Harney, A. Colegrove, P. Lough, and U. Meth, "GSAKMP
Token Specification", draft-ietf-msec-tokenspec-sec-00.txt. Token Specification", draft-ietf-msec-tokenspec-sec-00.txt.
[RFC 3711] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K. [RFC 3711] M. Baugher, D. McGrew, M. Naslund, E. Carrara, and K.
Norrman, "The Secure Real-Time Transport Protocol (SRTP)", RFC 3711, Norrman, "The Secure Real-Time Transport Protocol (SRTP)", RFC 3711,
March 2004. March 2004.
[RFC 3740] T. Hardjono and B. Weis, "The Multicast Group Security [RFC 3740] T. Hardjono and B. Weis, "The Multicast Group Security
skipping to change at page 12, line 31 skipping to change at page 13, line 31
------------------------------------------------------------ ------------------------------------------------------------
-- Token ID -- Token ID
TokenID ::= SEQUENCE { TokenID ::= SEQUENCE {
groupName OCTET STRING, groupName OCTET STRING,
edition INTEGER OPTIONAL edition INTEGER OPTIONAL
} }
LifeDate ::= CHOICE { LifeDate ::= CHOICE {
gt [0] GeneralizedTime, gt GeneralizedTime,
utc [1] UTCTime, utc UTCTime,
interval [2] INTEGER interval INTEGER
} }
------------------------------------------------------------ ------------------------------------------------------------
-- Registration -- Registration
Registration ::= SEQUENCE { Registration ::= SEQUENCE {
register GroupMngmtProtocol, register GroupMngmtProtocol,
de-register GroupMngmtProtocol de-register GroupMngmtProtocol
} }
------------------------------------------------------------ ------------------------------------------------------------
-- GroupMngmtProtocol -- GroupMngmtProtocol
GroupMngmtProtocol ::= CHOICE { GroupMngmtProtocol ::= CHOICE {
none [0] NULL, none NULL,
supported [1] Protocol supported Protocol
} }
Protocol ::= SEQUENCE { Protocol ::= SEQUENCE {
protocol OBJECT IDENTIFIER, protocol OBJECT IDENTIFIER,
protocolInfo OCTET STRING protocolInfo OCTET STRING
} }
------------------------------------------------------------ ------------------------------------------------------------
-- DataProtocol -- DataProtocol
skipping to change at page 35, line 5 skipping to change at page 35, line 32
ambiguities. ambiguities.
D.4 Changes from Group Policy Token v-03 to v-04, September 2005 D.4 Changes from Group Policy Token v-03 to v-04, September 2005
- Authorization field for group senders. - Authorization field for group senders.
- Editorial corrections. - Editorial corrections.
- Renamed to "Group Security Policy Token". - Renamed to "Group Security Policy Token".
D.5 Changes from Group Policy Token v-04 to v-05, December 2005
- Removed constraints on CMS signing-time attribute.
- Removed unnecessary explicit tags in CHOICE constructs of the
core token.
Authors' Addresses Authors' Addresses
Andrea Colegrove Andrea Colegrove
SPARTA, Inc. SPARTA, Inc.
7075 Samuel Morse Drive 7075 Samuel Morse Drive
Columbia, MD 21046 Columbia, MD 21046
(410) 872-1515 ext 232 (410) 872-1515 ext 232
FAX (410) 872-8079 FAX (410) 872-8079
acc@sparta.com acc@sparta.com
skipping to change at page 36, line 18 skipping to change at page 37, line 18
use of such proprietary rights by implementers or users of this use of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Document expiration: March 30, 2006 Document expiration: June 16, 2006
 End of changes. 26 change blocks. 
87 lines changed or deleted 108 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/