Technical Summary
This document describes the use of the SEED [RFC4269] block cipher
algorithm in the Secure Real-time Transport Protocol (SRTP) [RFC3711] for
providing confidentiality for the Real-time Transport Protocol (RTP)
[RFC3550] traffic and for the control traffic for RTP, the Real-time
Transport Control Protocol (RTCP) [RFC3550].
Working Group Summary
The document has been reviewed by the AVT working group to ensure
consistency with SRTP.
Document Quality
There are implementations of SEED and this draft specifies how to use
it for SRTP
Personnel
Roni Even is the document shepherd.
Robert Sparks is the Responsible AD (Cullen Jennings was the prior
responsible AD).
Review was provided by David McGrew and Eric Rescorla.
RFC Editor Note:
1. Replace existing entire text in Section 1.1 with the following text
(the following text is copied verbatum from RFC4162):
SEED is a symmetric encryption algorithm that was developed by Korea
Information Security Agency (KISA) and a group of experts, beginning
in 1998. The input/output block size of SEED is 128-bit and the key
length is also 128-bit. SEED has the 16-round Feistel structure. A
128-bit input is divided into two 64-bit blocks and the right 64-bit
block is an input to the round function with a 64-bit subkey
generated from the key scheduling.
SEED is easily implemented in various software and hardware because
it is designed to increase the efficiency of memory storage and the
simplicity of generating keys without degrading the security of the
algorithm. In particular, it can be effectively adopted in a
computing environment that has a restricted resources such as mobile
devices, smart cards, and so on.
SEED is a national industrial association standard [TTASSEED] and is
widely used in South Korea for electronic commerce and financial
services operated on wired & wireless PKI.
The algorithm specification and object identifiers are described in
[SEED-ALG]. The SEED homepage,
http://www.kisa.or.kr/seed/seed_eng.html, contains a wealth of
information about SEED, including detailed specification, evaluation
report, test vectors, and so on.
2. Section 5,
OLD:
"Mandatory-to-implement" means conformance to the specification, and
that Table 1 does not supersede a similar table in Section 5 of
[RFC3711]. An RTP implementation that supports SEED MUST implement
the modes listed in Table 1.
NEW:
"Mandatory-to-implement" means conformance to this specification, and
.............................................^^^^^^^^^^^^^^^^^^^^^^
"to this specification"
that Table 1 does not supersede a similar table in Section 5 of
[RFC3711]. An RTP implementation that supports SEED MUST implement
the modes listed in Table 1.