[kitten] AES-GCM for Kerberos GSS-API

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[kitten] AES-GCM for Kerberos GSS-API

Luke Howard
I had a bit of a play with adding support for AES-GCM to Heimdal. Notes:

* GCM is added as a RFC 3961 enctype, but it’s really a pseudo-enctype – were it to be documented, it might not be at the 3961 layer at all (except camping on the enctype namespace for negotiation).

* The target application is only GSS, and it’s assumed it'd be negotiated using RFC4537.

* Encryption/decryption functions are extended to support associated data (this was already there in the implementation, but 3961 would need to be updated).

* KDF is SP800-108 in counter/feedback mode with CMAC, this is used both for key derivation and for RFC4401 PRF. (Wasn’t sure if was safe to use GMAC here?)

   Ke  = KDF-CMAC(base-key, usage | 0xAA)
   PRF = KDF-CMAC(base-key, "prf" | octet-string)

There is no Ki/Kc because there is no separate checksum or integrity usage.

* No string-to-key function is defined.

* No checksum types are defined, instead MIC tokens are constructed using the encryption function with an empty plaintext. I figured this was less intrusive than extending the checksum function to take a cipher state parameter, but comments are welcome.

* The cipher state is the GCM initialisation vector length; the length is 96 bits (excluding counter). A (key, IV) combination must never be reused. TOK_ID || Flags || 0xFF || SND_SEQ is used as the initialisation vector for all RFC 4121 tokens.

* The encrypted copy of the 4121 token header is removed (it is protected by the IV, except for the EC field which implementations must validate independently). We could additionally protect it as associated data.

Implementation (forked off aes-sha2 work):


— Luke

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AES-GCM for Kerberos GSS-API

Luke Howard

> * The cipher state is the GCM initialisation vector length; the length is 96 bits (excluding counter). A (key, IV) combination must never be reused. TOK_ID || Flags || 0xFF || SND_SEQ is used as the initialisation vector for all RFC 4121 tokens.

Poorly worded - the cipher state is the GCM IV, the GCM IV is 96 bits long.
_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AES-GCM for Kerberos GSS-API

Luke Howard
In reply to this post by Luke Howard

On 7 Dec 2015, at 7:52 PM, Luke Howard <[hidden email]> wrote:

* KDF is SP800-108 in counter/feedback mode with CMAC, this is used both for key derivation and for RFC4401 PRF. (Wasn’t sure if was safe to use GMAC here?)

   Ke  = KDF-CMAC(base-key, usage | 0xAA)
   PRF = KDF-CMAC(base-key, "prf" | octet-string)

I can’t find much about using a GMAC-based KDF, and I have no idea how safe it is in this usage with a constant IV. Still, if it’s possible, it would certainly be nice and symmetrical.

— Luke

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AES-GCM for Kerberos GSS-API

Luke Howard

On 7 Dec 2015, at 11:44 PM, Luke Howard <[hidden email]> wrote:


On 7 Dec 2015, at 7:52 PM, Luke Howard <[hidden email]> wrote:

* KDF is SP800-108 in counter/feedback mode with CMAC, this is used both for key derivation and for RFC4401 PRF. (Wasn’t sure if was safe to use GMAC here?)

   Ke  = KDF-CMAC(base-key, usage | 0xAA)
   PRF = KDF-CMAC(base-key, "prf" | octet-string)

I can’t find much about using a GMAC-based KDF, and I have no idea how safe it is in this usage with a constant IV. Still, if it’s possible, it would certainly be nice and symmetrical.

I did find this however:


— Luke

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AES-GCM for Kerberos GSS-API

Benjamin Kaduk-2
On Mon, 7 Dec 2015, Luke Howard wrote:

>
> > On 7 Dec 2015, at 11:44 PM, Luke Howard <[hidden email]> wrote:
> >
> >
> >> On 7 Dec 2015, at 7:52 PM, Luke Howard <[hidden email] <mailto:[hidden email]>> wrote:
> >>
> >> * KDF is SP800-108 in counter/feedback mode with CMAC, this is used both for key derivation and for RFC4401 PRF. (Wasn’t sure if was safe to use GMAC here?)
> >>
> >>    Ke  = KDF-CMAC(base-key, usage | 0xAA)
> >>    PRF = KDF-CMAC(base-key, "prf" | octet-string)
> >
> >
> > I can’t find much about using a GMAC-based KDF, and I have no idea how safe it is in this usage with a constant IV. Still, if it’s possible, it would certainly be nice and symmetrical.
>
> I did find this however:
>
> http://marc.info/?l=cfrg&m=143336328026648&w=2 <http://marc.info/?l=cfrg&m=143336328026648&w=2>
> https://www.ietf.org/mail-archive/web/cfrg/current/msg02689.html <https://www.ietf.org/mail-archive/web/cfrg/current/msg02689.html>
Perhaps I am just remembering those posts, but I do agree that GMAC is not
appropriate for KDF usage.


> * No checksum types are defined, instead MIC tokens are constructed
> using the encryption function with an empty plaintext. I figured this
> was less intrusive than extending the checksum function to take a cipher
> state parameter, but comments are
> welcome.

That seems reasonable at first glance.

I did not get to take a glance at the code itself yet, but thanks for
putting together the proof-of-concept.  Do you have any performance
numbers for comparison?

-Ben
_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AES-GCM for Kerberos GSS-API

Luke Howard

> On 8 Dec 2015, at 9:08 AM, Benjamin Kaduk <[hidden email]> wrote:
>
> I did not get to take a glance at the code itself yet, but thanks for
> putting together the proof-of-concept.  Do you have any performance
> numbers for comparison?

Not yet but given this is the principal motivation for GCM, I should really get some together. Will do.

— Luke

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AES-GCM for Kerberos GSS-API

Luke Howard
In reply to this post by Luke Howard

On 7 Dec 2015, at 7:52 PM, Luke Howard <[hidden email]> wrote:

* The cipher state is the GCM initialisation vector length; the length is 96 bits (excluding counter). A (key, IV) combination must never be reused. TOK_ID || Flags || 0xFF || SND_SEQ is used as the initialisation vector for all RFC 4121 tokens.

FWIW I took a quick look at IPsec (RFC4106 s8.1) and we could use that approach for IV construction – make the key length 20 (or 36) bytes and construct the IV as:

last four bytes Ke || SND_SEQ

however this lacks a direction bit, so we’d most likely need to steal the high bit from SND_SEQ which halves the number of messages that can be transmitted (perhaps not a practical issue).

Nico doesn’t think this is worth worrying about (GCM spec says that it’s OK to have a completely deterministic IV as long as it’s not reused with the same key), but perhaps the extra entropy / consistency with TLS/IPsec is a good idea?

— Luke

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AES-GCM for Kerberos GSS-API

Luke Howard
OK, I changed the implementation to more closely reflect other IETF usage of GCM. This gives the IV some more entropy I assume is not a bad thing.

The RFC3961 key length is now 20 bytes for aes128-gcm-128 and 36 bytes for aes128-gcm-128; the last four bytes are used to salt the IV in the same manner as TLS and IPsec.

The initialisation vector exposed at the 3961 level is now only eight bytes long and this meeds to include both a direction flag and the sequence number. Hence only 2^63 messages can be sent before the sequence number wraps (not a problem with Heimdal which only uses 32-bit sequence numbers, but perhaps an issue with other implementations). The first bit of the initialisation vector is set if the message is sent by the acceptor, unset if not.

Because the IV now only protects the sequence number, rather than most of the token header, the entire token header is input as the last item of associated data, for both Wrap and MIC tokens. (We could just include the first 8 bytes but I see no reason not to protect the entire header.)
 
Thoughts welcome (I know Nico thinks this change was not necessary!).

— Luke
_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AES-GCM for Kerberos GSS-API

Greg Hudson
In reply to this post by Luke Howard
On 12/07/2015 07:28 PM, Luke Howard wrote:
> Nico doesn’t think this is worth worrying about (GCM spec says that it’s
> OK to have a completely deterministic IV as long as it’s not reused with
> the same key), but perhaps the extra entropy / consistency with
> TLS/IPsec is a good idea?

I agree with Nico; I think this is extra complexity we don't want or need.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AES-GCM for Kerberos GSS-API

Luke Howard

> On 8 Dec 2015, at 4:01 PM, Greg Hudson <[hidden email]> wrote:
>
> On 12/07/2015 07:28 PM, Luke Howard wrote:
>> Nico doesn’t think this is worth worrying about (GCM spec says that it’s
>> OK to have a completely deterministic IV as long as it’s not reused with
>> the same key), but perhaps the extra entropy / consistency with
>> TLS/IPsec is a good idea?
>
> I agree with Nico; I think this is extra complexity we don't want or need.

OK. Are you OK with not protecting the token header in the MAC (i.e. asserting valid values of EC and relying on the IV)?

— Luke
_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AES-GCM for Kerberos GSS-API

Martin Rex-2
In reply to this post by Luke Howard
Luke Howard wrote:

>
>> Luke Howard <[hidden email]> wrote:
>>
>>> Luke Howard <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>> * KDF is SP800-108 in counter/feedback mode with CMAC, this is used
>>>   both for key derivation and for RFC4401 PRF. (Wasn't sure if was
>>>   safe to use GMAC here?)
>>>
>>>    Ke  = KDF-CMAC(base-key, usage | 0xAA)
>>>    PRF = KDF-CMAC(base-key, "prf" | octet-string)
>>
>>
>> I can't find much about using a GMAC-based KDF, and I have no idea
>> how safe it is in this usage with a constant IV. Still, if it's
>> possible, it would certainly be nice and symmetrical.
>
> I did find this however:
>
> http://marc.info/?l=cfrg&m=143336328026648&w=2
> https://www.ietf.org/mail-archive/web/cfrg/current/msg02689.html


I assume that the hash function for use in the key derivation
needs to have cryptographic hash properties.


NIST SP 800-38D "Galois/Counter Mode (GCM) and GMAC",
2nd paragraph on page 10 of NIST SP 800-38D

http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf

   GHASH is a keyed hash function but not, on its own, a cryptographic
   hash function. This Recommendation only approves GHASH for use within
   the context of GCM.


-Martin

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AES-GCM for Kerberos GSS-API

Luke Howard
If we profile for GSS only, we could (ignoring
GSS PRF for a second) eliminate the need for key derivation entirely as there is no Kc/Ki and the token ID in the IV disambiguates Wrap from MIC usage.

But this might be risky if we are defining this at the 3961 level unless we can mandate the usage be part of the IV (but that means increasing the IV size which affects performance and also changes some of the NIST guarantees about safety IIRC).

Thoughts? Seems simplest to align with 3961 as closely as possible if defining at this layer, else if defining at GSS layer we can be more creative.

Sent from my iPhone

> On 8 Dec 2015, at 19:09, Martin Rex <[hidden email]> wrote:
>
> Luke Howard wrote:
>>
>>> Luke Howard <[hidden email]> wrote:
>>>
>>>> Luke Howard <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>> * KDF is SP800-108 in counter/feedback mode with CMAC, this is used
>>>>  both for key derivation and for RFC4401 PRF. (Wasn't sure if was
>>>>  safe to use GMAC here?)
>>>>
>>>>   Ke  = KDF-CMAC(base-key, usage | 0xAA)
>>>>   PRF = KDF-CMAC(base-key, "prf" | octet-string)
>>>
>>>
>>> I can't find much about using a GMAC-based KDF, and I have no idea
>>> how safe it is in this usage with a constant IV. Still, if it's
>>> possible, it would certainly be nice and symmetrical.
>>
>> I did find this however:
>>
>> http://marc.info/?l=cfrg&m=143336328026648&w=2
>> https://www.ietf.org/mail-archive/web/cfrg/current/msg02689.html
>
>
> I assume that the hash function for use in the key derivation
> needs to have cryptographic hash properties.
>
>
> NIST SP 800-38D "Galois/Counter Mode (GCM) and GMAC",
> 2nd paragraph on page 10 of NIST SP 800-38D
>
> http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
>
>   GHASH is a keyed hash function but not, on its own, a cryptographic
>   hash function. This Recommendation only approves GHASH for use within
>   the context of GCM.
>
>
> -Martin

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AES-GCM for Kerberos GSS-API

Nico Williams
In reply to this post by Luke Howard
On Tue, Dec 08, 2015 at 04:47:21PM +1100, Luke Howard wrote:
> > On 8 Dec 2015, at 4:01 PM, Greg Hudson <[hidden email]> wrote:
> > On 12/07/2015 07:28 PM, Luke Howard wrote:
> >> Nico doesn’t think this is worth worrying about (GCM spec says that it’s
> >> OK to have a completely deterministic IV as long as it’s not reused with
> >> the same key), but perhaps the extra entropy / consistency with
> >> TLS/IPsec is a good idea?
> >
> > I agree with Nico; I think this is extra complexity we don't want or need.

In particular: a deterministic IV construction is the key to preventing
key/IV reuse, _and_, we only need entropy in the key.

Entropy in the IV doesn't help security because whatever bits of it are
randomly chosen have to be sent in the clear as otherwise the peer won't
be able to reconstruct them.  The IV cannot be secret for GSS because of
the out of sequence token delivery/consumption requirement (well, it's
an option, but one we want).

For an RFC3961 octet stream application like AFS' rx the initial IV
could be secret and non-deterministic, thereafter just a counter.  In
this case entropy in the IV might increase security, but we don't need
that to make the enctype secure for GSS.

Entropy in the IV doesn't help UNLESS you just cannot construct a
deterministic IV.  Since here we can, we should not have any entropy in
the IV.

> OK. Are you OK with not protecting the token header in the MAC (i.e.
> asserting valid values of EC and relying on the IV)?

Putting the header into the IV necessarily protects the header.

This lets us have a savings of 16 bytes (no confounder) and 16 more
bytes (no header added to the plaintext), and costs us 4 bytes (the
integrity tag is 128 bits instead of 96 for the AES CTS HMAC-SHA1
enctypes), saving us a total of 28 bytes of overheade for wrap with
confidentiality tokens.  This is huge for small tokens, and a big
performance improvement: less data to transmit, less to move around, and
two fewer block operations, at no extra cost for protecting the header,
plus it's now parallelizable, and the integrity tag computation is
faster than HMAC-SHA-1.

The whole header is 128 bits and doesn't fit in 96 bits, but there are
five bytes that don't need protection, and if in a pinch we could
squeeze two more bytes out of the header.  So making the IV this is good
enough:

  TOK_ID || Flags || 0xFF || SEND_SEQ

The EC field is going to be a constant in all cases for these enctypes.
And the RRC field has never needed integrity protection.  That's the
four bytes we drop from the header to form the IV.

This leaves us with 32 bits of counter for the message data, which means
64GB wrap token w/ confidentiality max size.  64GB is plenty for this.

(There's only three TOK_ID values of interest here, and only three flags
bits used, so we could fold the TOK_ID into flags, leaving us with three
bytes for whatever we want, if we needed them.  But we don't need them.)

Nico
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AES-GCM for Kerberos GSS-API

Luke Howard
Note that in my proposal - based on IPSec - the entropy came from the last four bytes of the acceptor sub session key (having made that 20 instead of 16 bytes) so it wasn't sent in the clear, but I agree it probably adds no utility. It looks as if this exists in IPSec because keys may be reused, which we're asserting is not the case in the GSS profile.

Sent from my iPhone

> On 9 Dec 2015, at 09:36, Nico Williams <[hidden email]> wrote:
>
> On Tue, Dec 08, 2015 at 04:47:21PM +1100, Luke Howard wrote:
>>> On 8 Dec 2015, at 4:01 PM, Greg Hudson <[hidden email]> wrote:
>>>> On 12/07/2015 07:28 PM, Luke Howard wrote:
>>>> Nico doesn’t think this is worth worrying about (GCM spec says that it’s
>>>> OK to have a completely deterministic IV as long as it’s not reused with
>>>> the same key), but perhaps the extra entropy / consistency with
>>>> TLS/IPsec is a good idea?
>>>
>>> I agree with Nico; I think this is extra complexity we don't want or need.
>
> In particular: a deterministic IV construction is the key to preventing
> key/IV reuse, _and_, we only need entropy in the key.
>
> Entropy in the IV doesn't help security because whatever bits of it are
> randomly chosen have to be sent in the clear as otherwise the peer won't
> be able to reconstruct them.  The IV cannot be secret for GSS because of
> the out of sequence token delivery/consumption requirement (well, it's
> an option, but one we want).
>
> For an RFC3961 octet stream application like AFS' rx the initial IV
> could be secret and non-deterministic, thereafter just a counter.  In
> this case entropy in the IV might increase security, but we don't need
> that to make the enctype secure for GSS.
>
> Entropy in the IV doesn't help UNLESS you just cannot construct a
> deterministic IV.  Since here we can, we should not have any entropy in
> the IV.
>
>> OK. Are you OK with not protecting the token header in the MAC (i.e.
>> asserting valid values of EC and relying on the IV)?
>
> Putting the header into the IV necessarily protects the header.
>
> This lets us have a savings of 16 bytes (no confounder) and 16 more
> bytes (no header added to the plaintext), and costs us 4 bytes (the
> integrity tag is 128 bits instead of 96 for the AES CTS HMAC-SHA1
> enctypes), saving us a total of 28 bytes of overheade for wrap with
> confidentiality tokens.  This is huge for small tokens, and a big
> performance improvement: less data to transmit, less to move around, and
> two fewer block operations, at no extra cost for protecting the header,
> plus it's now parallelizable, and the integrity tag computation is
> faster than HMAC-SHA-1.
>
> The whole header is 128 bits and doesn't fit in 96 bits, but there are
> five bytes that don't need protection, and if in a pinch we could
> squeeze two more bytes out of the header.  So making the IV this is good
> enough:
>
>  TOK_ID || Flags || 0xFF || SEND_SEQ
>
> The EC field is going to be a constant in all cases for these enctypes.
> And the RRC field has never needed integrity protection.  That's the
> four bytes we drop from the header to form the IV.
>
> This leaves us with 32 bits of counter for the message data, which means
> 64GB wrap token w/ confidentiality max size.  64GB is plenty for this.
>
> (There's only three TOK_ID values of interest here, and only three flags
> bits used, so we could fold the TOK_ID into flags, leaving us with three
> bytes for whatever we want, if we needed them.  But we don't need them.)
>
> Nico
> --

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AES-GCM for Kerberos GSS-API

Nico Williams
On Wed, Dec 09, 2015 at 09:46:01AM +1100, Luke Howard wrote:
> Note that in my proposal - based on IPSec - the entropy came from the
> last four bytes of the acceptor sub session key (having made that 20

But in that case no new entropy was contributed anyways...

> instead of 16 bytes) so it wasn't sent in the clear, but I agree it
> probably adds no utility. It looks as if this exists in IPSec because
> keys may be reused, which we're asserting is not the case in the GSS
> profile.

Correct.  Senders never reuse sequence numbers; session keys are chosen
randomly, and hopefully never reused.  Initial sequence numbers are also
chosen randomly (so, in fact, we get some entropy in the IV after all!
just indirectly), though monotonically increasing thereafter.

A bad RNG could result in the same session keys (and initial sequence
numbers) being chosen repeatedly, but only sessions will be compromised,
not long-term keys nor Ticket session keys.

IPsec is a very different beast.

Nico
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

[kitten] RFC 3961 AEAD extensions

Luke Howard
In reply to this post by Luke Howard
This document defines extensions to RFC 3961 for use with AEAD ciphers that require deterministic initialisation vectors (such as GCM), by allowing encryption types to modify their behaviour depending on whether they are being used with long-term keys or not.

https://www.ietf.org/id/draft-howard-krb-aead-00.txt

— Luke
_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AES-GCM for Kerberos GSS-API

Luke Howard
In reply to this post by Greg Hudson

> On 8 Dec 2015, at 4:01 PM, Greg Hudson <[hidden email]> wrote:
>
> On 12/07/2015 07:28 PM, Luke Howard wrote:
>> Nico doesn’t think this is worth worrying about (GCM spec says that it’s
>> OK to have a completely deterministic IV as long as it’s not reused with
>> the same key), but perhaps the extra entropy / consistency with
>> TLS/IPsec is a good idea?
>
> I agree with Nico; I think this is extra complexity we don't want or need.

Reading RFC 3610 Section 5, this would help guard against pre-computation attacks, but so does the choice of a random initial sequence number in the AP-REQ (RFC 1510 section 3.2.2).

Anyway, on your advice I did not pursue this approach.

— Luke

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] RFC 3961 AEAD extensions

Greg Hudson
In reply to this post by Luke Howard
On 12/13/2015 08:33 PM, Luke Howard wrote:
> This document defines extensions to RFC 3961 for use with AEAD ciphers that require deterministic initialisation vectors (such as GCM), by allowing encryption types to modify their behaviour depending on whether they are being used with long-term keys or not.

I am tentatively okay with reserving points in the enctype namespace for
use with GSS AEAD enctypes (I'll call them that even though they could
be used by other protocols), so that we can use RFC 4537 enctype
negotiation during the AP-REQ/AP-REP exchange to negotiate their use.

I am tentatively opposed to sharing any part of the abstract API between
RFC 3961 ciphers and these GSS AEAD enctypes.  There's too much
potential for misuse.

I think we can avoid having to define a KDF (and therefore bring in
dependencies on additional primitives, such as SHA-256 for
chacha20-poly1305).  We may not need an analog to "key usage numbers" at
all, as these enctypes are only for use with ephemeral keys, never with
the same key across multiple protocols.  If we do determine a need for
key usage numbers, I think they could be included at the beginning of
the additional data for each message.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] RFC 3961 AEAD extensions

Luke Howard
Hi Greg,

Thanks for the quick feedback.

> I am tentatively opposed to sharing any part of the abstract API between
> RFC 3961 ciphers and these GSS AEAD enctypes.  There's too much
> potential for misuse.

Right, this is the alternate approach: define a single update to RFC 4121 for use with AEAD encryption types, where RFC 3961 is imported purely in order to leverage RFC 4537 enctype negotiation. From an implementation perspective: for Heimdal, it was ostensibly easier to implement this at the RFC 3961 layer. I agree it is probably impossible to completely guard against misuse. For the record I did the following to mitigate against misuse in my Heimdal implementation:

* No string-to-key function or associated checksum types will make most non-AEAD usages fail
* IV must be non-NULL on call to encrypt/decrypt
* AEAD encryption types unavailable except through krb5_encrypt_iov_ivec API
* Encryption type enumerate APIs hide any AEAD types unless the consumer is RFC 4537

Jeff: would be good to hear your thoughts on how useful GCM/etc are for non-GSS-API use (e.g. OpenAFS).

> I think we can avoid having to define a KDF (and therefore bring in
> dependencies on additional primitives, such as SHA-256 for
> chacha20-poly1305).  We may not need an analog to "key usage numbers" at
> all, as these enctypes are only for use with ephemeral keys, never with
> the same key across multiple protocols.  If we do determine a need for
> key usage numbers, I think they could be included at the beginning of
> the additional data for each message.

Good point. Yes, if this is really a RFC 4121 only profile, then TOK_ID is sufficient to disambiguate the Wrap and MIC usages, and we do not need any key derivation.

— Luke
_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] RFC 3961 AEAD extensions

Luke Howard
In reply to this post by Greg Hudson
Another approach is that we do actually define an approach for long-term keys (although I’m not sure how we’d do this elegantly with existing Unix APIs – perhaps checking for the absence of a HEADER in the IOV APIs).

KDF for long-term keys could be KDF(base-key, confounder | usage | 0xAA). I’m sure there are other workable constructions.

But – this is all additional complexity for implementations to deal with.

— Luke
_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
12