New Version Notification for draft-mcgrew-iv-gen-01.txt
David McGrew <mcgrew <at> cisco.com>
2011-10-31 15:28:17 GMT
Hi,
an updated version of the draft just went in. It has text to address
some comments from reviewers; there is a diff below with the new text.
regards,
David
Begin forwarded message:
>
> A new version of I-D, draft-mcgrew-iv-gen-01.txt has been
> successfully submitted by David McGrew and posted to the IETF
> repository.
>
> Filename: draft-mcgrew-iv-gen
> Revision: 01
> Title: Generation of Deterministic Initialization Vectors (IVs)
> and Nonces
> Creation date: 2011-10-31
> WG ID: Individual Submission
> Number of pages: 25
>
> Abstract:
> Many cryptographic algorithms use deterministic IVs, including CTR,
> GCM, CCM, GMAC. This type of IV is also called a (deterministic)
> nonce. Deterministic IVs must be distinct, for each fixed key, to
> guarantee the security of the algorithm. This note describes best
> practices for the generation of such IVs, and summarizes how they
> are
> generated and used in different protocols. Some problem areas are
> highlighted, and test considerations are outlined. This note will
> be
> useful to implementers of algorithms using deterministic IVs, and to
> protocol or system designers using them.
>
< Internet-Draft Deterministic IV Generation July
2011
---
> Internet-Draft Deterministic IV Generation October
2011
343,345c343,345
< [RFC4106], TLS [RFC5288], SSH [RFC5647], and SRTP . The way that
< these protocols define their IVs is outlined in this section and is
< summarized in Table 1.
---
> [RFC4106], TLS [RFC5288], SSH [RFC5647], and SRTP [RFC3711].
The way
> that these protocols define their IVs is outlined in this
section and
> is summarized in Table 1.
> The partially implicit format can save on bandwidth or data
storage
> requirements, because it avoids sending or storing the implicit
part
> of the IV. However, it limits the number of IVs that can be
> generated, because the implicit part is fixed, and it adds
complexity
> to the system, by making the system coordinate the implicit part
> through out-of-band means. Thus, new protocol and system designs
> SHOULD NOT use the partially implicit format unless a review of
all
> of the issues shows that the bandwidth or storage savings are
worth
> the complexity. (An alternative strategy for bandwidth savings is
> discussed in Section 7.4.)
>
< Fixed field and the Counter field are concatenated, then they are
< bitwise exclusive-ored with the Salt field, and the resulting value
< is the IV. The Counter is incremented, treating it as an unsigned
< integer with the most significant byte on the left, and the stored
< Counter field is set to the incremented value. Then the IV is
< returned.
---
> stored Counter value MUST be checked to determine if an IV can be
> generated; an IV can only be generated if the value of Counter + 1
> does not exceed the maximum allowable value of the Counter
field. If
> an IV cannot be generated, then the operation returns an
indication
> that there are no more IVs that are available. Otherwise, the
Fixed
> field and the Counter field are concatenated, then they are
bitwise
> exclusive-ored with the Salt field, and the resulting value is the
> IV. The Counter is incremented, treating it as an unsigned
integer
> with the most significant byte on the left, and the stored Counter
> field is set to the incremented value. Then the IV is returned.
> 7.4. Bandwidth Use
>
> An implicit or partially implicit IV uses less bandwidth than a
full-
> sized IV. But as noted above, the (partially) implicit IV format
> reduces the number of IVs that can be generated and adds
complexity
> to the system.
>
> An alternative approach to bandwidth savings in a protocol
design is
> to use a predictable IV format, such as that of Section 4.1, and
then
> apply header compression to the IV. Header compression is often
used
> on bandwidth-constrained links, and it can be applied to encrypted
> packets [RFC3095]. The format of Section 4.1 can easily be
handled
> by header compression. This approach has several benefits: it
makes
> IV generation simpler, it allows bandwidth savings for
environments
> in which it matters while putting the complexity burden onto the
> systems that opt to realize those savings, and it increases the
> number of IVs that can be used. Specifications that use this
design
> alternative SHOULD require the use of the IV format in Section
4.1.
>
>
> Almost all cryptographic systems can implement counter-based
> deterministic IVs. In many cases, it is straightforward to
generate
> deterministic IVs associated with a short-term key in use by a
single
> encrypter, as in a typical point-to-point protocol. Complications
> can arise, however, when there are multiple encrypters, or when
a key
> is used for an extended period of time. Cryptographic systems
that
> cannot ensure IV distinctness should not use deterministic IVs,
and
> should instead use a misuse-resistant mode of operation such as
the
> Synthetic Initialization Vector (SIV) Authenticated Encryption
mode
> of operation [RFC5295], or a randomized algorithm such as the CBC
> mode of operation (though an additional authentication mechanism
must
> be used with that option). If authentication but not encryption
is
> required, then it is possible to use an algorithm that does not
> require an IV, such as HMAC [RFC2104].
>
RSS Feed