NIST comments on counter mode

[Barbara Fraser <byfraser@cisco.com>]

Folks,

Last August when the issue of FIPS-140 evaluation was mentioned, Ted and
I dropped a quick note to NIST to get their input. Arguably, we should
have cc'd the wg but at the time we were also trying to cool some heated
communications. That being said, it does make sense to get this exchange
included in the working group archives, and this week I asked and
received permission from Bill Burr to forward his email to the 
list.

Barb

============

X-Sender: wburr@email.nist.gov
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 14 Aug 2002 13:56:04 -0400
From: Bill Burr <william.burr@nist.gov>
Subject: Re: AES Counter Mode and SHA-256

Ted,

It may well be that it would be cleaner from an implementation and
validation point of view to separate the encryption counter field from
the packet sequence.  

I suspect that, if you were making a totally new IPSec implementation
from scratch, or designing the whole protocol from scratch, it wouldn't
be any big deal to use the packet sequence counter as the encryption
counter.  But I would imagine that, when you are adding a new
counter encryption mode to an existing IPSec protocol or implementation,
it might well simplify your life to use a separate counter IV field,
because otherwise you might well need to expand the crypto module
boundary significantly to encompass a counter driven from the packet
sequence number, and you may not have built your existing code with that
in mind at all.  I can't believe that killing the two birds with the
one counter makes FIPS 140 validation impossible, but I could easily
believe that it might double your implementation and validation costs for
the counter mode, or worse.

My intuition tells me that the cleanest, easiest way to add a secure,
easily validated counter mode in IPSEC is to use a separate counter IV in
every packet.  This comes, of course, at the expense of extra
overhead in every packet.  But we at NIST are not the best people to
estimate the cost to actual implementations of validating either
solution.  

I'm just saying that NIST isn't a priori ruling out driving your
counter from your packet sequence number.  In fact that is the sort
of thing we had thought a lot of folks would want to do.

Bill Burr

At 12:08 PM 8/14/02 -0400, Theodore Ts'o wrote:

On Wed, Aug 14, 2002 at 11:00:42AM -0400, Bill Burr wrote:
>
> So the bottom line is that an implicit counter synchronization mechanism
> should not itself any bar to FIPS 140-2 validation of IPSEC implantations
> of a counter mode.  But in cryptography, the details matter, and we don't
> have a lot of  counter mode FIPS 140 precedent yet to work from.  Pioneers
> in FIPS new kinds of 140 validations, like pioneers generally, tend to step
> in unmarked holes.  When we allow the kind of flexibility we have with
> counter mode, that makes the validation lab's job harder, and we have to
> come up with the precise test requirements that the labs must apply.
>

Bill,

Thanks for your comments.  The specific question which has come up is
with AES counter mode, and whether or not the IV should be generated
from the normal IPSEC packet sequence, or whether the IV should be
divorced from the IPSEC packet sequence number.

The argument in favor of divorcing the AES counter mode IV from the
IPSEC sequence counter is that it means that the code which handles
the IPSEC packet sequence number (which would drag in largish portions
of the IKE implementation) into the parts of the code which would need
to be validated for FIPS 140 purposes.  If a separate field were used,
which was included in the ESP headers, then (so the argument goes)
only the ESP implementation would need FIPS 140 validation.  (Steve,
please correct me if I haven't stated your concerns cogently.)

The argument on the other side of this issue is that the extra field
adds bulk to the packet size, and this overhead might be an issue in
certain applications.

There are unsettled points on both sides of this issue.  On the
"overhead is bad" side, it is unclear whether or not the overhead is
in fact really a major problem, since it depends very much on the
application, and complete details of example applications where this
would be a problem has yet to be forthcoming.

On the "keep the code that needs to be evaluated small" argument, I
don't yet understand what the impacts would be of (in the worst case)
the entire IKE implementation in a FIPS 140 validation.  Does it make
the validation impossible?  Does it raise the costs by a factor of 2?
10?  100?  1000?

Many thanks for taking the time to look at this issue.

                                                - Ted

William E. Burr
NIST
Manager, Security Technology Group
301-975-2914
william.burr@nist.gov