7. Transport protocols
MIKEY MAY be integrated within session establishment protocols.
Currently, integration of MIKEY within SIP/SDP and RTSP is defined in
[KMASDP]. MIKEY MAY use other transports, in which case how MIKEY is
transported over such a transport protocol has to be defined.
What has been discussed up to now is not limited to single peer-to-
peer communication (except for the DH method), but can be used to
distribute group keys for small-size interactive groups and simple
one-to-many scenarios. Section 2.1. describes the scenarios in the
focus of MIKEY. This section describes how MIKEY is used in a group
scenario (though, see also Section 4.3 for issues related to
8.1. Simple one-to-many
--------+-------------- - -
| | |
v v v
++++ ++++ ++++
|A | |B | |C |
| | | | | |
++++ ++++ ++++
Figure 8.1. Simple one-to-many scenario.
In the simple one-to-many scenario, a server is streaming to a small
group of clients. RTSP or SIP is used for the registration and the
key management set up. The streaming server acts as the Initiator of
MIKEY. In this scenario, the pre-shared key or public key transport
mechanism will be appropriate in transporting the same TGK to all the
clients (which will result in common TEKs for the group).
Note, if the same TGK/TEK(s) should be used by all the group members,
the streaming server MUST specify the same CSB_ID and CS_ID(s) for
the session to all the group members.
As the communication may be performed using multicast, the members
need a common security policy if they want to be part of the group.
This limits the possibility of negotiation.
Furthermore, the Initiator should carefully consider whether to
request the verification message in reply from each receiver, as this
may result in a certain load for the Initiator itself as the group
8.2. Small-size interactive group
As described in the overview section, for small-size interactive
groups, one may expect that each client will be in charge for setting
up the security for its outgoing streams. In these scenarios, the
pre-shared key or the public-key transport method is used.
|A | -------> |B |
| | <------- | |
^ | | ^
| | | |
| | ++++ | |
| --->|C |<--- |
Figure 8.2. Small-size group without a centralized controller.
One scenario may then be that the client sets up a three-part call,
using SIP. Due to the small size of the group, unicast SRTP is used
between the clients. Each client sets up the security for its
outgoing stream(s) to the others.
As for the simple one-to-many case, the streaming client specifies
the same CSB_ID and CS_ID(s) for its outgoing sessions if the same
TGK/TEK(s) is used for all the group members.
9. Security Considerations
Key management protocols based on timestamps/counters and one-
roundtrip key transport have previously been standardized, for
example ISO [ISO1, ISO2]. The general security of these types of
protocols can be found in various articles and literature, c.f. [HAC,
No chain is stronger than its weakest link. If a given level of
protection is wanted, then the cryptographic functions protecting the
keys during transport/exchange MUST offer a security corresponding to
at least that level.
For instance, if a security against attacks with a complexity 2^96 is
wanted, then one should choose a secure symmetric cipher supporting
at least 96 bit keys (128 bits may be a practical choice) for the
actual media protection, and a key transport mechanism that provides
equivalent protection, e.g., MIKEY's pre-shared key transport with
128 bit TGK, or RSA with 1024 bit keys (which according to [LV]
corresponds to the desired 96 bit level, with some margin).
In summary, key size for the key-exchange mechanism MUST be weighed
against the size of the exchanged TGK so that it at least offers the
required level. For efficiency reasons, one SHOULD also avoid a
security overkill, e.g., by not using a public key transport with
public keys giving a security level that is orders of magnitude
higher than length of the transported TGK. We refer to [LV] for
concrete key size recommendations.
Moreover, if the TGKs are not random (or pseudo-random), a brute
force search may be facilitated, again lowering the effective key
size. Therefore, care MUST be taken when designing the (pseudo-)
random generators for TGK generation, see [FIPS][RAND].
For the selection of the hash function, SHA-1 with 160-bit output is
the default one. In general, hash sizes should be twice the
"security level", indicating that SHA-1-256, [SHA256], should be used
for the default 128-bit level. However, due to the real-time aspects
in the scenarios we are treating, hash sizes slightly below 256 are
acceptable, as the normal "existential" collision probabilities would
be of secondary importance.
In a Crypto Session Bundle, the Crypto Sessions can share the same
TGK as discussed earlier. From a security point of view, to satisfy
the criterion in case the TGK is shared, the encryption of the
individual Crypto Sessions are performed "independently". In MIKEY,
this is accomplished by having unique Crypto Session identifiers (see
also Section 4.1) and a TEK derivation method that provides
cryptographically independent TEKs to distinct Crypto Sessions
(within the Crypto Session Bundle), regardless of the security
Specifically, the key derivations, as specified in Section 4.1, are
implemented by a pseudo-random function. The one used here is a
simplified version of that used in TLS [TLS]. Here, only one single
hash function is used, whereas TLS uses two different functions.
This choice is motivated by the high confidence in the SHA-1 hash
function, and by efficiency and simplicity of design (complexity does
not imply security). Indeed, as shown in [DBJ], if one of the two
hashes is severely broken, the TLS PRF is actually less secure than
as if a single hash had been used on the whole key, as is done in
In the pre-shared key and public-key schemes, the TGK is generated by
a single party (Initiator). This makes MIKEY somewhat more sensitive
if the Initiator uses a bad random number generator. It should also
be noted that neither the pre-shared nor the public-key scheme
provides perfect forward secrecy. If mutual contribution or perfect
forward secrecy is desired, the Diffie-Hellman method is to be used.
Authentication (e.g., signatures) in the Diffie-Hellman method is
required to prevent man-in-the-middle attacks.
Forward/backward security: if the TGK is exposed, all generated TEKs
are compromised. However, under the assumption that the derivation
function is a pseudo-random function, disclosure of an individual TEK
does not compromise other (previous or later) TEKs derived from the
same TGK. The Diffie-Hellman mode can be considered by cautious
users, as it is the only one that supports so called perfect forward
secrecy (PFS). This is in contrast to a compromise of the pre-shared
key (or the secret key of the public key mode), where future sessions
and recorded sessions from the past are then also compromised.
The use of random nonces (RANDs) in the key derivation is of utmost
importance to counter off-line pre-computation attacks. Note however
that update messages re-use the old RAND. This means that the total
effective key entropy (relative to pre-computation attacks) for k
consecutive key updates, assuming the TGKs and RAND are each n bits
long, is about L = n*(k+1)/2 bits, compared to the theoretical
maximum of n*k bits. In other words, a 2^L work effort MAY enable an
attacker to get all k n-bit keys, which is better than brute force
(except when k = 1). While this might seem like a defect, first note
that for a proper choice of n, the 2^L complexity of the attack is
way out of reach. Moreover, the fact that more than one key can be
compromised in a single attack is inherent to the key exchange
problem. Consider for instance a user who, using a fixed 1024-bit
RSA key, exchanges keys and communicates during a one or two year
lifetime of the public key. Breaking this single RSA key will enable
access to all exchanged keys and consequently the entire
communication of that user over the whole period.
All the pre-defined transforms in MIKEY use state-of-the-art
algorithms that have undergone large amounts of public evaluation.
One of the reasons for using the AES-CM from SRTP [SRTP], is to have
the possibility of limiting the overall number of different
encryption modes and algorithms, while offering a high level of
security at the same time.
9.2. Key lifetime
Even if the lifetime of a TGK (or TEK) is not specified, it MUST be
taken into account that the encryption transform in the underlying
security protocol can in some way degenerate after a certain amount
of encrypted data. It is not possible to here state universally
applicable, general key lifetime bounds; each security protocol
should define such maximum amount and trigger a re-keying procedure
before the "exhaustion" of the key. For example, according to SRTP
[SRTP] the TEK, together with the corresponding TGK, MUST be changed
at least every 2^48 SRTP packet.
Still, the following can be said as a rule of thumb. If the security
protocol uses an "ideal" b-bit block cipher (in CBC mode, counter
mode, or a feedback mode, e.g., OFB, with full b-bit feedback),
degenerate behavior in the crypto stream, possibly useful for an
attacker, is (with constant probability) expected to occur after a
total of roughly 2^(b/2) encrypted b-bit blocks (using random IVs).
For security margin, re-keying MUST be triggered well in advance
compared to the above bound. See [BDJR] for more details.
For use of a dedicated stream cipher, we refer to the analysis and
documentation of said cipher in each specific case.
The use of timestamps, instead of challenge-responses, requires the
systems to have synchronized clocks. Of course, if two clients are
not synchronized, they will have difficulties in setting up the
security. The current timestamp based solution has been selected to
allow a maximum of one roundtrip (i.e., two messages), but still
provide a reasonable replay protection. A (secure) challenge-
response based version would require at least three messages. For a
detailed description of the timestamp and replay handling in MIKEY,
see Section 5.4.
Practical experiences of Kerberos and other timestamp-based systems
indicate that it is not always necessary to synchronize the terminals
over the network. Manual configuration could be a feasible
alternative in many cases (especially in scenarios where the degree
of looseness is high). However, the choice must be made carefully
with respect to the usage scenario.
9.4. Identity Protection
User privacy is a complex matter that to some extent can be enforced
by cryptographic mechanisms, but also requires policy enforcement and
various other functionalities. One particular facet of privacy is
user identity protection. However, identity protection was not a
main design goal for MIKEY. Such a feature will add more complexity
to the protocol and was therefore not chosen to be included. As
MIKEY is anyway proposed to be transported over, e.g., SIP, the
identity may be exposed by this. However, if the transporting
protocol is secured and also provides identity protection, MIKEY
might inherit the same feature. How this should be done is for
9.5. Denial of Service
This protocol is resistant to Denial of Service attacks in the sense
that a Responder does not construct any state (at the key management
protocol level) before it has authenticated the Initiator. However,
this protocol, like many others, is open to attacks that use spoofed
IP addresses to create a large number of fake requests. This may for
example, be solved by letting the protocol transporting MIKEY do an
IP address validity test. The SIP protocol can provide this using
the anonymous authentication challenge mechanism (specified in
Section 22.1 of [SIP]).
It is highly RECOMMENDED to include IDr in the Initiator's message.
If not included, its absence can be used for DoS purposes (the
largest DoS-impact being on the public key and DH methods), where a
message intended for other entities is sent to the target. In fact,
the target may verify the signature correctly due to the fact that
the Initiator's ID is correct and the message is actually signed by
the claimed Initiator (e.g., by re-directing traffic from another
However, in the public key method, the envelop key and the MAC will
ensure that the message is not accepted (still, compared to a normal
faked message, where the signature verification would detect the
problem, one extra public key decryption is needed to detect the
problem in this case).
In the DH method, a message would be accepted (without detecting the
error) and a response (and state) would be created for the malicious
As also discussed in Section 5.4, the tradeoff between time
synchronization and the size of the replay cache may be affected in
case of for example, a flooding DoS attack. However, if the
recommendations of using a dynamic size of the replay cache are
followed, it is believed that the client will in most cases be able
to handle the replay cache. Of course, as the replay cache decreases
in size, the required time synchronization is more restricted.
However, a bigger problem during such an attack would probably be to
process the messages (e.g., verify signatures/MACs) due to the
computational workload this implies.
9.6. Session Establishment
It should be noted that if the session establishment protocol is
insecure, there may be attacks on this that will have indirect
security implications on the secured media streams. This however
only applies to groups (and is not specific to MIKEY). The threat is
that one group member may re-direct a stream from one group member to
another. This will have the same implication as when a member tries
to impersonate another member, e.g., by changing its IP address. If
this is seen as a problem, it is RECOMMENDED that a Data Origin
Authentication (DOA) scheme (e.g., digital signatures) be applied to
the security protocol.
Re-direction of streams can of course be done even if it is not a
group. However, the effect will not be the same as compared to a
group where impersonation can be done if DOA is not used. Instead,
re-direction will only deny the receiver the possibility of receiving
(or just delay) the data.
10. IANA Considerations
This document defines several new name spaces associated with the
MIKEY payloads. This section summarizes the name spaces for which
IANA is requested to manage the allocation of values. IANA is
requested to record the pre-defined values defined in the given
sections for each name space. IANA is also requested to manage the
definition of additional values in the future. Unless explicitly
stated otherwise, values in the range 0-240 for each name space
SHOULD be approved by the process of IETF consensus and values in the
range 241-255 are reserved for Private Use, according to [RFC2434].
The name spaces for the following fields in the Common header payload
(from Section 6.1) are requested to be managed by IANA (in bracket is
the reference to the table with the initially registered values):
* data type (Table 6.1.a)
* Next payload (Table 6.1.b)
* PRF func (Table 6.1.c). This name space is between 0-127, where
values between 0-111 should be approved by the process of IETF
consensus and values between 112-127 are reserved for Private Use.
* CS ID map type (Table 6.1.d)
The name spaces for the following fields in the Key data transport
payload (from Section 6.2) are requested to be managed by IANA:
* Encr alg (Table 6.2.a)
* MAC alg (Table 6.2.b)
The name spaces for the following fields in the Envelope data payload
(from Section 6.3) are requested to be managed by IANA:
* C (Table 6.3)
The name spaces for the following fields in the DH data payload (from
Section 6.4) are requested to be managed by IANA:
* DH-Group (Table 6.4)
The name spaces for the following fields in the Signature payload
(from Section 6.5) are requested to be managed by IANA:
* S type (Table 6.5)
The name spaces for the following fields in the Timestamp payload
(from Section 6.6) are requested to be managed by IANA:
* TS type (Table 6.6)
The name spaces for the following fields in the ID payload and the
Certificate payload (from Section 6.7) are requested to be managed by
* ID type (Table 6.7.a)
* Cert type (Table 6.7.b)
The name spaces for the following fields in the Cert hash payload
(from Section 6.8) are requested to be managed by IANA:
* Hash func (Table 6.8)
The name spaces for the following fields in the Security policy
payload (from Section 6.10) are requested to be managed by IANA:
* Prot type (Table 6.10)
For each security protocol that uses MIKEY, a set of unique
parameters MAY be registered.
From Section 6.10.1.
* SRTP Type (Table 6.10.1.a)
* SRTP encr alg (Table 6.10.1.b)
* SRTP auth alg (Table 6.10.1.c)
* SRTP PRF (Table 6.10.1.d)
* FEC order (Table 6.10.1.e)
The name spaces for the following fields in the Error payload (from
Section 6.12) are requested to be managed by IANA:
* Error no (Table 6.12)
The name spaces for the following fields in the Key data payload
(from Section 6.13) are requested to be managed by IANA:
* Type (Table 6.13.a). This name space is between 0-16, which
should be approved by the process of IETF consensus.
* KV (Table 6.13.b). This name space is between 0-16, which should
be approved by the process of IETF consensus.
The name spaces for the following fields in the General Extensions
payload (from Section 6.15) are requested to be managed by IANA:
* Type (Table 6.15).
10.1. MIME Registration
This section gives instructions to IANA to register the
application/mikey MIME media type. This registration is as follows:
MIME media type name : application
MIME subtype name : mikey
Required parameters : none
Optional parameters : version
version: The MIKEY version number of the enclosed message
(e.g., 1). If not present, the version defaults to 1.
Encoding Considerations : binary, base64 encoded
Security Considerations : see section 9 in this memo
Interoperability considerations : none
Published specification : this memo
The authors would like to thank Mark Baugher, Ran Canetti, Martin
Euchner, Steffen Fries, Peter Barany, Russ Housley, Pasi Ahonen (with
his group), Rolf Blom, Magnus Westerlund, Johan Bilien, Jon-Olov
Vatn, Erik Eliasson, and Gerhard Strangar for their valuable
12.1. Normative References
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
[NAI] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998.
[PSS] PKCS #1 v2.1 - RSA Cryptography Standard, RSA Laboratories,
June 14, 2002, www.rsalabs.com
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
[SHA-1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
[SRTP] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real Time Transport Protocol", RFC
3711, March 2004.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
[X.509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[AESKW] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, September 2002.
12.2. Informative References
[AKE] Canetti, R. and H. Krawczyk, "Analysis of Key-Exchange
Protocols and their use for Building Secure Channels",
Eurocrypt 2001, LNCS 2054, pp. 453-474, 2001.
[BDJR] Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, "A
Concrete Analysis of Symmetric Encryption: Analysis of the
DES Modes of Operation", in Proceedings of the 38th
Symposium on Foundations of Computer Science, IEEE, 1997,
[BMGL] Hastad, J. and M. Naslund: "Practical Construction and
Analysis of Pseduo-randomness Primitives", Proceedings of
Asiacrypt 2001, LNCS. vol 2248, pp. 442-459, 2001.
[DBJ] Johnson, D.B., "Theoretical Security Concerns with TLS use
of MD5", Contribution to ANSI X9F1 WG, 2001.
[FIPS] "Security Requirements for Cryptographic Modules", Federal
Information Processing Standard Publications (FIPS PUBS)
140-2, December 2002.
[GKMARCH] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Group Key Management Architecture", Work in Progress.
[GDOI] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
[GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., and R.
Fleischer, "Group Secure Association Key Management
Protocol", Work in Progress.
[HAC] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook
of Applied Cryptography", CRC press, 1996.
[IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[ISO1] ISO/IEC 9798-3: 1997, Information technology - Security
techniques - Entity authentication - Part 3: Mechanisms
using digital signature techniques.
[ISO2] ISO/IEC 11770-3: 1997, Information technology - Security
techniques - Key management - Part 3: Mechanisms using
digital signature techniques.
[ISO3] ISO/IEC 18014 Information technology - Security techniques
- Time-stamping services, Part 1-3.
[KMASDP] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "Key Management Extensions for SDP and RTSP", Work
[LOA] Burrows, Abadi, and Needham, "A logic of authentication",
ACM Transactions on Computer Systems 8 No.1 (Feb. 1990),
[LV] Lenstra, A. K. and E. R. Verheul, "Suggesting Key Sizes for
Cryptosystems", http://www.cryptosavvy.com/suggestions.htm[NTP] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RAND] Eastlake, 3rd, D., Crocker, S., and J. Schiller,
"Randomness Requirements for Security", RFC 1750, December
[RTSP] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[SHA256] NIST, "Description of SHA-256, SHA-384, and SHA-512",
http://csrc.nist.gov/encryption/shs/sha256-384-512.pdf[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol - Version 1.0",
RFC 2246, January 1999.
Appendix A. MIKEY - SRTP Relation
The terminology in MIKEY differs from the one used in SRTP as MIKEY
needs to be more general, nor is tight to SRTP only. Therefore, it
might be hard to see the relations between keys and parameters
generated in MIKEY and those used by SRTP. This section provides
some hints on their relation.
MIKEY | SRTP
Crypto Session | SRTP stream (typically with related SRTCP stream)
Data SA | input to SRTP's crypto context
TEK | SRTP master key
The Data SA is built up by a TEK and the security policy exchanged.
SRTP may use an MKI to index the TEK or TGK (the TEK is then derived
from the TGK that is associated with the corresponding MKI), see
A.1. MIKEY-SRTP Interactions
In the following, we give a brief outline of the interface between
SRTP and MIKEY and the processing that takes place. We describe the
SRTP receiver side only, the sender side will require analogous
1. When an SRTP packet arrives at the receiver and is processed, the
triple <SSRC, destination address, destination port> is extracted
from the packet and used to retrieve the correct SRTP crypto
context, hence the Data SA. (The actual retrieval can, for
example, be done by an explicit request from the SRTP
implementation to MIKEY, or, by the SRTP implementation accessing
a "database", maintained by MIKEY. The application will typically
decide which implementation is preferred.)
2. If an MKI is present in the SRTP packet, it is used to point to
the correct key within the SA. Alternatively, if SRTP's <From,
To> feature is used, the ROC||SEQ of the packet is used to
determine the correct key.
3. Depending on whether the key sent in MIKEY (as obtained in step 2)
was a TEK or a TGK, there are now two cases.
- If the key obtained in step 2 is the TEK itself, it is used
directly by SRTP as a master key.
- If the key instead is a TGK, the mapping with the CS_ID
(internal to MIKEY, Section 6.1.1) allows MIKEY to compute the
correct TEK from the TGK as described in Section 4.1 before
SRTP uses it.
If multiple TGKs (or TEKs) are sent, it is RECOMMENDED that each TGK
(or TEK) be associated with a distinct MKI. It is RECOMMENDED that
the use of <From, To> in this scenario be limited to very simple
cases, e.g., one stream only.
Besides the actual master key, other information in the Data SA
(e.g., transform identifiers) will of course also be communicated
from MIKEY to SRTP.
Phone: +358 40 5079256
Phone: +46 8 50877040
Phone: +46 8 58531705
Phone: +46 8 58533739
Phone: +46 8 4044502
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
Funding for the RFC Editor function is currently provided by the