On Tue, May 15, 2007 at 06:29:47PM +0400, lamo at ccs.ru wrote:
> Dan McDonald wrote:
> > On Tue, May 15, 2007 at 05:02:51PM +0400, lamo at ccs.ru wrote:
> >> Hi all,
> >>
> >> I've got a question about implementing combined mode algorithm to be
> >> used in IPsec.
> >
> > Is it a well-known algorithm? We haven't used any such algorithms in our
> > IPsec yet - your experience would benefit the community.
>
> No. It's not a well-known algorithm. But the ability to use such type of
> combined mode algorithm is written in RFC 4303. I think it'd be great to
> have OpenSolaris IPsec implementation to support *both* types of
> combined mode algorithm (if it turns to be possible, because it may be
> too algorithm-specific).
I see - you're looking at section 3.2.3 of 4303, which says:
For example, the SPI and Sequence Number fields might be replicated
within the ciphertext envelope and an ICV may be appended to the ESP
trailer. None of these details should be observable externally.
And that will be needed to be taken into account for some algorithms... just
not any that are specified today.
Can you share your cipher with us as well? Or is it some sort of classified
algorithm? It'll be VERY hard to justify supporting the second kind of
cipher without some publishable algorithm that exploits the
copy-SPI-and-replay field.
> I've read it before starting my work ( as well as RFC 4309 - AES CCM). And
> it's an example of the other type of the combined mode algorithm
> i.e. integrity for (data that is encrypted + additional data which is not
> encrypted). The same is true for rfc 4309.
Both AES modes take the ESP/replay into their calculations, but without
adding 'em to the ciphertext. It's called AAD (Additional Authentication
Data).
> Please, correct me if I'm wrong.
I think you're right.f
> > If there's shortcomings for combined-mode algorithms in our ESP, ESP's
> > interfaces to/from the Crypto Framework, or both, this would be a fine time
> > to address 'em.
> >
> > Off the top of my head:
> >
> > - I *think* ipsecalgs(1M) may need to be extended to indicate a
> > combined-mode cipher. Right now I think we assume all the world's
> > CBC, which isn't accurate.
> >
> > - We may need help in the IPsec-to-Crypto interfaces. I know the
> > crypto folks are working on AES-CCM for reasons not related to
> > IPsec. It's most likely we could get RFC 4309 (AES-CCM with ESP)
> > working before RFC 4106 (AES-GCM).
>
> To the best of my knowledge, atm, you have to do nothing (global) to
> current IPsec implementation to use AES-CCM and AES-GCM besides
> actually writing this algorithms' kernel modules:)
How do you pass the values that need to be included but aren't part of the
explicit ciphertext? I don't see how to do that. We need a way to pass AAD
into a combined-mode cipher. We have a way to do it with MAC algorithms, but
not with ciphers.
> But to add the second type we ( community if you offer us such
> opportunity of course) have to discuss the best way to modify current
> IPsec implementation and (very probably) IPsec-to-Crypto interfaces. It
> will depend upon the way we choose to implement (i.e. just extendind the
> Payload Data or provide additional space which will be on of the
> argument to kCF functions or another way).
We're going to have to account for AAD whether or not we copy it into the
packet's ciphertext.
> > If you're ready to get combined-mode ciphers working with ESP, we're ready
> > to
> > help. It's an architectural issue, so we'll need to ARC it, but don't let
> > that bother you.
>
> I'm ready:)
I wish you could share your copy-AAD-into-ciphertext algorithm. As it is, if
you can wait for the crypto folks to deliver AES-CCM, then you could get
AES-CCM working with IPsec!
Thanks!
Dan
