Subject: [Ipsec] AES Algorithm Negotiation in IKE

From: Russ Housley <[email-masked]>
Date: Thu, 28 Oct 2004 14:58:19 -0400

Dear IPsec WG:

We have documents that specify three modes of AES.  They are AES-CBC, 
AES-CTR, AES-CCM, and AES-GCM.  In each case, these documents register an 
algorithm identifier with IANA.  Since only one of these has achieved RFC 
status so far, only AES-CBC actually has a number yet:

    AES-CBC has been assigned number 7 [see RFC 3602].

Since the AES supports three key lengths, the Key Length attribute must be 
specified in the IKE Phase 2 exchange.  Of course, the Key Length attribute 
value can be either 128, 192, or 256.

AES is the only commonly-implemented algorithm that requires key length 
negotiation, and there have been reports of interoperability problems in 
this area.

Two of the AES modes (AES-CCM and AES-GCM) provide confidentiality and 
integrity.  Both of these AES modes offer more than one integrity check 
value (ICV) size.  How do we want to negotiate the ICV size for a 
particular security association.  I see three choices.

First, we could do it the same way that we do AES key size.  That is, IKE 
could negotiate another algorithm-specific value.  Given the 
interoperability issues with key length, I am not sure this is the right 
approach.

Second, we could assign an algorithm identifier for each ICV size.  This 
approach leads to many IANA registry entries, but no new IKE code is needed 
to support any of the AES modes.

Third, we could decide that the negotiation of key length was also a 
mistake.  This approach would lead to three times as many IANA registry 
entries as the previous approach, but it might be a quick solution to the 
interoperability concerns.

I would like to hear from the working group.  What is the best way forward.

Russ

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Fri, 29 Oct 2004 01:30:36 +0200

IMO the keylength attribute is well-specified, at least in the IKEv2 
document.  If there are going to be interoperability issues then it 
means that somebody is not implementing it correctly.

I would go with option #1.

If only AES-CBC has a number, I'm wondering why the cryptographic 
suites document went with AES-CTR?

On 28/10/2004, at 20:58, Russ Housley wrote:

> AES-CTR, AES-CCM, and AES-GCM.  In each case, these documents register 
> an algorithm identifier with IANA.  Since only one of these has 
> achieved RFC status so far, only AES-CBC actually has a number yet:
>
> Since the AES supports three key lengths, the Key Length attribute 
> must be specified in the IKE Phase 2 exchange.  Of course, the Key 
> Length attribute value can be either 128, 192, or 256.
>
> AES is the only commonly-implemented algorithm that requires key 
> length negotiation, and there have been reports of interoperability 
> problems in this area.
>
> integrity.  Both of these AES modes offer more than one integrity 
> check value (ICV) size.  How do we want to negotiate the ICV size for 
> a particular security association.  I see three choices.
>
> First, we could do it the same way that we do AES key size.  That is, 
> IKE could negotiate another algorithm-specific value.  Given the 
> interoperability issues with key length, I am not sure this is the 
> right approach.
>
> Second, we could assign an algorithm identifier for each ICV size.  
> This approach leads to many IANA registry entries, but no new IKE code 
> is needed to support any of the AES modes.
>
> mistake.  This approach would lead to three times as many IANA 
> registry entries as the previous approach, but it might be a quick 
> solution to the interoperability concerns.
>

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 28 Oct 2004 20:12:49 -0700

>means that somebody is not implementing it correctly.

Of course, but that is what has happened in a couple of cases. We 
have been fortunate in our AES interop testing at VPNC to not have 
any systems in the lab be mis-implemented, but I have heard from at 
least two different vendors that they didn't get it right the first 
time.

>I would go with option #1.

Inventing a new algorithm-specific identifier seems silly from an 
interop standpoint, given that we have essentially no experience with 
it in common deployments. It seems like the table in #2 would be a 
lot easier for implementers to get right the first time.

--Paul Hoffman, Director
--VPN Consortium

---

From: Francis Dupont <[email-masked]>
Date: Fri, 29 Oct 2004 11:22:54 +0200

In your previous mail you wrote:

   We have documents that specify three modes of AES.  They are AES-CBC, 
                                  ^^^^^ ?
   AES-CTR, AES-CCM, and AES-GCM.

=> transform IDs are on 16 bits (1-1023 for IANA): I am in favor of
this third solution.

Regards

[email-masked]

---

From: Paul Koning <[email-masked]>
Date: Fri, 29 Oct 2004 11:13:49 -0400

>>>>> "Yoav" == Yoav Nir <[email-masked]> writes:

 Yoav> IMO the keylength attribute is well-specified, at least in the
 Yoav> IKEv2 document.  If there are going to be interoperability
 Yoav> issues then it means that somebody is not implementing it
 Yoav> correctly.

 Yoav> I would go with option #1.

I agree.  

Implementing little protocol details like the key length element isn't
rocket science.  I don't see any good reason to hack up the spec to
accommodate buggy implementations.  For one thing, there's no reason
to believe it will help.  What's there now is the right approach.

Similarly, ICV length for the combined algorithms should be another
parameter just like the key length -- not encoded in the algorithm
ID.  

     paul

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 29 Oct 2004 11:11:42 -0700

At 11:13 AM -0400 10/29/04, Paul Koning wrote:
>accommodate buggy implementations.

There is no spec hacking here: the spec explicitly allows for both 
algorithm IDs and parameters.

>   For one thing, there's no reason

There is nothing in 2409 about ICV length.

>parameter just like the key length -- not encoded in the algorithm

Let me push back on this and ask for real-world implementers: do you 
agree here? That it would be better to create a new 
algorithm-specific parameter and use the current parameter system 
rather than two additional algorithms IDs for CCM and zero additional 
algorithm IDs for GCM?

If it is so important that we add new ICV parameters, why wasn't this 
discussed in any of the rounds of either protocols, even in the WG 
and IETF last calls?

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Koning <[email-masked]>
Date: Fri, 29 Oct 2004 15:29:20 -0400

>>>>> "Paul" == Paul Hoffman </ VPNC <[email-masked]>> writes:

 Paul> At 11:13 AM -0400 10/29/04, Paul Koning wrote:
 >> Implementing little protocol details like the key length element
 >> isn't rocket science.  I don't see any good reason to hack up the
 >> spec to accommodate buggy implementations.

 Paul> There is no spec hacking here: the spec explicitly allows for
 Paul> both algorithm IDs and parameters.

Sure, but the design all along has been that the algorithm ID selects
the algorithm, and parameters carry algorithm variables such as key
length. 

 >> For one thing, there's no reason to believe it will help.  What's
 >> there now is the right approach.

 Paul> There is nothing in 2409 about ICV length.

No, but key length has been around for a while.

 >> Similarly, ICV length for the combined algorithms should be
 >> another parameter just like the key length -- not encoded in the
 >> algorithm ID.

 Paul> Let me push back on this and ask for real-world implementers:
 Paul> do you agree here? That it would be better to create a new
 Paul> algorithm-specific parameter and use the current parameter
 Paul> system rather than two additional algorithms IDs for CCM and
 Paul> zero additional algorithm IDs for GCM?

 Paul> If it is so important that we add new ICV parameters, why
 Paul> wasn't this discussed in any of the rounds of either protocols,
 Paul> even in the WG and IETF last calls?

If the issue is that it's too late to add the missing parameter, and
variable ICV length is needed, then I guess using multiple algorithm
IDs is a sensible workaround.  In that case, I would find either
approach acceptable.

That wasn't my main point.  My main point was about the key length
parameter.  As an implementer, I find it perfectly straightforward to
deal with a key length parameter for algorithms that have a use for
one.  

It sounded like the issue with key length was that some
implementations didn't implement it right.  Ok, so fix them, what's
the big deal?  If we establish a precedent of changing the spec rather
than the implementation when an implementation has a bug, we will
never have a stable spec.

Russ's original note said:

That's the part I disagree with.  

    paul koning

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 29 Oct 2004 13:19:20 -0700

>the algorithm, and parameters carry algorithm variables such as key

Except that it wasn't used for many years after the spec was 
implemented because there wasn't a commonly-used encryption algorithm 
that needed it until AES. I can't say exactly what people had 
problems with, but I can say that I had at least two implementers who 
said "we got it wrong the first time we tried" (and that they had 
fixed the problem before it got to the VPNC interop testing).

>IDs is a sensible workaround.  In that case, I would find either

Good to hear. It's never too late, of course, but if we go that 
route, it means yanking two RFCs out of the RFC Editor's queue, and 
postponing a third one that is hopefully ready to go into the queue. 
All of them would have to be revised to include the new parameter and 
a description of how to fill it in, and therefore they each would 
have to go through IETF last calls again and go through the IESG 
again. (I tried to type that without using my whiny voice, but I 
don't think I succeeded.)

>the big deal?

No big deal, and they did fix them. There are plenty of systems that 
do AES interoperably; see <http://www.vpnc.org/testing.html>.

>   If we establish a precedent of changing the spec rather

Completely agree.

It is complicated by the fact that RFC 2409 could not anticipate 
something like AES. The wording about key size is:

      When using an Encryption Algorithm that has a variable length key,
      this attribute specifies the key length in bits. (MUST use network
      byte order). This attribute MUST NOT be used when the specified
      Encryption Algorithm uses a fixed length key.

It can be argued that AES-128 and AES-192 and AES-256 are different 
algorithms with fixed key sizes because they each use a different 
number of rounds of processing; it can be argued that they are the 
same algorithm that just has the number of rounds triggered by the 
key size. The person who decided to register AES for IKEv1 as a 
single algorithm that required the key size parameter may have felt 
better about the second interpretation.

>That's the part I disagree with.

Agree: going to #3 would be a bad idea because it could make things 
more difficult for current AES implementers.

--Paul Hoffman, Director
--VPN Consortium