[kitten] New EncTypes?

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

[kitten] New EncTypes?

Henry B Hotz
It seems to be time to do housecleaning on algorithms selections. Is anyone interested in adding a new enctype to Kerberos?

Why (else)?  Speaking strictly for myself, I’d like to see a mandatory-to-implement enctype that shares *nothing* with the current aes-sha1-hmac stuff. I’m speaking purely strategically and not from any mathematical suspicion of weakness. If someone discovers something fundamentally wrong with the math behind SHA1 or AES, then it might take out SHA2 or Camellia as well.

I have nothing specific against the “suite-B” proposal, but they’re not what I’d like to see. I assume the NSA is too busy riding the “post quantum” horse away from their DRBG fiasco to help finish it.

Just to throw some straw (just straw, not an actual strawman) on the table, how about something that uses one of the European stream cipher finalists with SHA-3?

--------

Finally, is anyone interested in doing a die-die-die draft for triple-des, or rc4?


Personal:  [hidden email]
Business: [hidden email]

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

Re: [kitten] New EncTypes?

Benjamin Kaduk-2
On Wed, 18 Nov 2015, Henry B (Hank) Hotz, CISSP wrote:

> It seems to be time to do housecleaning on algorithms selections. Is anyone interested in adding a new enctype to Kerberos?
>
> Why (else)?  Speaking strictly for myself, I’d like to see a
> mandatory-to-implement enctype that shares *nothing* with the current
> aes-sha1-hmac stuff. I’m speaking purely strategically and not from any
> mathematical suspicion of weakness. If someone discovers something
> fundamentally wrong with the math behind SHA1 or AES, then it might take
> out SHA2 or Camellia as well.
>
> I have nothing specific against the “suite-B” proposal, but they’re not
> what I’d like to see. I assume the NSA is too busy riding the “post
> quantum” horse away from their DRBG fiasco to help finish it.
>
> Just to throw some straw (just straw, not an actual strawman) on the
> table, how about something that uses one of the European stream cipher
> finalists with SHA-3?
I had heard mutterings elsewhere about a chacha20-poly1305 sort of thing,
which seems potentially interesting to me.  The real question is whether
implementors would pick up such a thing, and whether we can get consensus
for MTI.

There are public commitments to funding at least one implementation of the
aes-cts-hmac-sha2 proposal, but I don't think I've heard anything one way
or the other about a completely novel enctype.


> Finally, is anyone interested in doing a die-die-die draft for triple-des, or rc4?

There is already
https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-00

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

Re: [kitten] New EncTypes?

Henry B Hotz

> On Nov 18, 2015, at 6:39 PM, Benjamin Kaduk <[hidden email]> wrote:
>
> On Wed, 18 Nov 2015, Henry B (Hank) Hotz, CISSP wrote:
>
>> It seems to be time to do housecleaning on algorithms selections. Is anyone interested in adding a new enctype to Kerberos?
>>
>> Why (else)?  Speaking strictly for myself, I’d like to see a
>> mandatory-to-implement enctype that shares *nothing* with the current
>> aes-sha1-hmac stuff. I’m speaking purely strategically and not from any
>> mathematical suspicion of weakness. If someone discovers something
>> fundamentally wrong with the math behind SHA1 or AES, then it might take
>> out SHA2 or Camellia as well.
>>
>> I have nothing specific against the “suite-B” proposal, but they’re not
>> what I’d like to see. I assume the NSA is too busy riding the “post
>> quantum” horse away from their DRBG fiasco to help finish it.
>>
>> Just to throw some straw (just straw, not an actual strawman) on the
>> table, how about something that uses one of the European stream cipher
>> finalists with SHA-3?
>
> I had heard mutterings elsewhere about a chacha20-poly1305 sort of thing,
> which seems potentially interesting to me.  The real question is whether
> implementors would pick up such a thing, and whether we can get consensus
> for MTI.
>
> There are public commitments to funding at least one implementation of the
> aes-cts-hmac-sha2 proposal, but I don't think I've heard anything one way
> or the other about a completely novel enctype.

It’s the difference between fixing known weaknesses and (trying) to protect against unknown ones.

>> Finally, is anyone interested in doing a die-die-die draft for triple-des, or rc4?
>
> There is already
> https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-00

OK, love the name. ;-) On quick scan the content looks good too. I guess I missed it because I didn’t have my current job yet, and my life was a bit unstable.

I’ll certainly put in a strong second as being supportive of that draft (with TBD nits). However, as several have said on saag, we need to make sure we have enough good algorithms available if we want to depreciate algorithms.

> -Ben


Personal:  [hidden email]
Business: [hidden email]

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

Re: [kitten] New EncTypes?

Rick van Rein (OpenFortress)
In reply to this post by Henry B Hotz
Hello,

> It seems to be time to do housecleaning on algorithms selections. Is
> anyone interested in adding a new enctype to Kerberos?
>
One thing I would like to bring into any such discussion is that it
would be possible to use through PKCS #11, the de-facto standard for
storing keys on tokens, including hardware keys that will never share
keys directly but allow their use through the API.  This extends the
range of possible uses for Kerberos, I think.

For instance, AES-CTS-HMAC uses plain standard AES and HMAC, and CTS can
be implemented in terms of standard CBC, so it ought to be possible to
implement with PKCS #11 (not that I've already actually tried, but it
looks possible).


Of a similar stance, I've been wanting to see more Checksum Types, such
as SHA256/384/512, for use with my TLS-KDH work.

-Rick

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

Re: [kitten] New EncTypes?

Benjamin Kaduk-2
On Thu, 19 Nov 2015, Rick van Rein wrote:

> Hello,
>
> > It seems to be time to do housecleaning on algorithms selections. Is
> > anyone interested in adding a new enctype to Kerberos?
> >
> One thing I would like to bring into any such discussion is that it
> would be possible to use through PKCS #11, the de-facto standard for
> storing keys on tokens, including hardware keys that will never share
> keys directly but allow their use through the API.  This extends the
> range of possible uses for Kerberos, I think.

It is probably premature to insist on this as a requirement, but it can
certainly be a part of the discussion.

> For instance, AES-CTS-HMAC uses plain standard AES and HMAC, and CTS can
> be implemented in terms of standard CBC, so it ought to be possible to
> implement with PKCS #11 (not that I've already actually tried, but it
> looks possible).

The argument would be more compelling if there was some prior art for it,
though -- I don't know of any hardware devices implementing such a scheme
at present.

> Of a similar stance, I've been wanting to see more Checksum Types, such
> as SHA256/384/512, for use with my TLS-KDH work.

Registering a new Checksum type is not particularly difficult, but seeing
that it gets implemented and used can be harder.  The de facto state of
affairs at present seems to be that Checksum types go hand-in-hand with
encryption types, and the required checksum for a given encryption type is
the only one ever used with it.  There may not be full support for using a
non-required checksum type with a given encryption type, but of course
use of checksums outside of traditional encryption types will require new
code anyway, so adding use of Checksums without encryption would not
present additional implementation effort other than that needed to
actually implement the new protocol feature.

-Ben

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

Re: [kitten] New EncTypes?

Viktor Dukhovni
In reply to this post by Henry B Hotz
On Wed, Nov 18, 2015 at 04:20:41PM -0800, Henry B (Hank) Hotz, CISSP wrote:

> It seems to be time to do housecleaning on algorithms selections. Is anyone
> interested in adding a new enctype to Kerberos?

Yes, but see below.

> Why (else)?  Speaking strictly for myself, I�d like to see a
> mandatory-to-implement enctype that shares *nothing* with the current
> aes-sha1-hmac stuff. I�m speaking purely strategically and not from any
> mathematical suspicion of weakness. If someone discovers something
> fundamentally wrong with the math behind SHA1 or AES, then it might take
> out SHA2 or Camellia as well.

Sharing nothing is much too radical, unlikely to get much adoption.
There is too much momentum behind AES (hardware support in modern
CPUs, ...) and no substantive evidence of any real concerns (beyond
the long-understood timing side-channel issues with naive software-only
implementations).

> Just to throw some straw (just straw, not an actual strawman) on the table,
> how about something that uses one of the European stream cipher finalists
> with SHA-3?

As a backup, sure, but SHA-3 is quite slow, and has no hardware
support.  The throught of GSSAPI wrap is largely dominated by SHA-1
performance these days.  We'd be much better off with OCB, or
another AEAD mode.

And we could use an updated set of AES enctypes, before jumping to
more exotic stream ciphers.

--
        Viktor.

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

Re: [kitten] New EncTypes?

Rick van Rein (OpenFortress)
In reply to this post by Benjamin Kaduk-2
Hi,

>> For instance, AES-CTS-HMAC uses plain standard AES and HMAC, and CTS can
>> be implemented in terms of standard CBC, so it ought to be possible to
>> implement with PKCS #11 (not that I've already actually tried, but it
>> looks possible).
>
> The argument would be more compelling if there was some prior art for it,
> though -- I don't know of any hardware devices implementing such a scheme
> at present.
Both AES and CBC are widely supported by PKCS #11 solutions, software
and hardware.
And CTS can be built on top of CBC, "from the outside" of the mode.  But
I do agree that
at least a demo would be nice to have.  Let's see if that drowns in my
TODO pile.

-Rick

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

Re: [kitten] New EncTypes?

Rick van Rein (OpenFortress)
In reply to this post by Benjamin Kaduk-2
Hello Benjamin,

>> For instance, AES-CTS-HMAC [...] ought to be possible to
>> implement with PKCS #11 (not that I've already actually tried, but it
>> looks possible).
>
> The argument would be more compelling if there was some prior art for it,
> though -- I don't know of any hardware devices implementing such a scheme
> at present.
I made a working demonstration that generates the test vectors for
AES128-CTS based on PKCS #11 stored AES key,
https://github.com/arpa2/kerberos-pkcs11

The demo comes to the boring conclusion that a diff between what it
generates and what was stripped from the RFC is empty:

shell> make
gcc -ggdb3 -DDEBUG -I
/usr/local/src/SoftHSMv2-with-OpenPGP/src/lib/cryptoki_compat/
-Wl,-rpath=/usr/local/src/SoftHSMv2-with-OpenPGP/src/lib/.libs
/usr/local/src/SoftHSMv2-with-OpenPGP/src/lib/.libs/libsofthsm.so  -o
aes128-cts-pkcs11 aes128-cts-pkcs11.c
./aes128-cts-pkcs11 > output.txt
Token PIN: sekreet
diff -u testvectors.txt output.txt
shell>

I ran this against SoftHSMv2 from the OpenDNSSEC project, but there is
no reason why it would not work on hardware tokens that implement the
same API; it only relies on CKK_AES and CKM_AES_CBC, which are not
special at all.

Enjoy,
 -Rick

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

Re: [kitten] New EncTypes?

Nico Williams
In reply to this post by Henry B Hotz
On Wed, Nov 18, 2015 at 04:20:41PM -0800, Henry B (Hank) Hotz, CISSP wrote:
> It seems to be time to do housecleaning on algorithms selections. Is
> anyone interested in adding a new enctype to Kerberos?

Luke's working on AEAD enctypes.

> Why (else)?  Speaking strictly for myself, I’d like to see a
> mandatory-to-implement enctype that shares *nothing* with the current
> aes-sha1-hmac stuff. I’m speaking purely strategically and not from
> any mathematical suspicion of weakness. If someone discovers something
> fundamentally wrong with the math behind SHA1 or AES, then it might
> take out SHA2 or Camellia as well.

It's hard not to share AES.  Nowadays CPUs can do AES in constant time,
very fast, in hardware.  That's hard to pass up.

Yes, AES in software is terrible for security, and an alternative would
be nice for systems that don't have AES HW.

> Just to throw some straw (just straw, not an actual strawman) on the
> table, how about something that uses one of the European stream cipher
> finalists with SHA-3?

AEAD enctypes seem a lot more appealing to me.

Luke's work will reduce the RFC4121/3962 overhead on GSS wrap tokens
with confidentiality by 28 bytes, and will reduce the number of block
operations by 2 blocks per wrap w/ conf token, as well as support
parallelization (in principle anyways).  Plus AEAD cipher modes can be
quite fast.

Nico
--

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

Re: [kitten] New EncTypes?

Nico Williams
In reply to this post by Rick van Rein (OpenFortress)
On Thu, Nov 19, 2015 at 08:30:18AM +0100, Rick van Rein wrote:
> > It seems to be time to do housecleaning on algorithms selections. Is
> > anyone interested in adding a new enctype to Kerberos?
> >
> One thing I would like to bring into any such discussion is that it
> would be possible to use through PKCS #11, the de-facto standard for
> storing keys on tokens, including hardware keys that will never share
> keys directly but allow their use through the API.  This extends the
> range of possible uses for Kerberos, I think.

It's kinda meaningless to use hardware tokens for Kerberos.

On the KDC side you'd have to put the entire KDC in the token for it to
be meaningful.  You can leave the KDB outside, but now all KDB records
have to be signed, and keys encrypted (the latter is generally
supported, but the former would require significant rototilling).  It's
easier instead to harden a KDC, building it like a large HSM.  On the
service side (including the TGS), your hardware tokens had better be
*fast* -- if not then forget it.  A TGS can be slow, if the HW is slow,
but throughput has to be reasonable, and total latency per-request below
the point at which clients timeout.

Hardware tokens make a lot more sense for PK-based protocols.  If you
really want HW tokens, then Kerberos is not for you.

I'd be much more interested in working on a DANE-based mech_dh
replacement than in working on putting a KDC in a token.  Such a mech
could have Kerberos-compatible principal naming and even attribute
certificates to match authorization-data.  Being PK- and DNSSEC-based
would mean cross-realm functionality would be present from the get-go,
and it'd mean that HW tokens would be meaningful from day one as well
(well, as meaningful as they are with any PK today).

> For instance, AES-CTS-HMAC uses plain standard AES and HMAC, and CTS can
> be implemented in terms of standard CBC, so it ought to be possible to
> implement with PKCS #11 (not that I've already actually tried, but it
> looks possible).

Solaris/Illumos implements CTS in terms of CBC, so, yes, it can be done.
It takes up to three calls to CBC, so HW latency can be a problem.  (See
above remarks.)

Nico
--

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

Re: [kitten] New EncTypes?

Rick van Rein (OpenFortress)
Hi Nico,

I was thinking of client-side tokens, not the KDC.
> It's kinda meaningless to use hardware tokens for Kerberos.

Symmetric keys reside on two ends, but the client will be much weaker in
its protection than the KDC; a reason for using PKCS #11 on the client
end is to uplift that level (and have better entropy than a password
supplies).  That would be an improvement even if the KDC was not changed
at all.  I agree that hardening the KDC can be pretty much comparable to
hardening an HSM.
> Hardware tokens make a lot more sense for PK-based protocols.  If you
> really want HW tokens, then Kerberos is not for you.

Yes and no... it's not a one-dimensional choice between PK and KRB5.

> I'd be much more interested in working on a DANE-based mech_dh
> replacement than in working on putting a KDC in a token.

I have a student working on that now :) and will send a project
description/proposal to at least MIT krb, and perhaps also Kitten,
sometime soon.

> Such a mech
> could have Kerberos-compatible principal naming and even attribute
> certificates to match authorization-data.  Being PK- and DNSSEC-based
> would mean cross-realm functionality would be present from the get-go,
> and it'd mean that HW tokens would be meaningful from day one as well
> (well, as meaningful as they are with any PK today).

PKINIT makes PK usable already, so I'm not sure why you bring
DNSSEC/DANE in here?  Do you want to improve on the cryptographic
strength of the initial password to protect AS?

Solaris/Illumos implements CTS in terms of CBC, so, yes, it can be done.
It takes up to three calls to CBC, so HW latency can be a problem.  (See
above remarks.)

Three is the total; encryption takes one CBC call, decryption takes two:
https://github.com/arpa2/kerberos-pkcs11/blob/master/aes128-cts-pkcs11.c#L221
https://github.com/arpa2/kerberos-pkcs11/blob/master/aes128-cts-pkcs11.c#L236
https://github.com/arpa2/kerberos-pkcs11/blob/master/aes128-cts-pkcs11.c#L241

Thanks,
 -Rick


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

Re: [kitten] New EncTypes?

Nico Williams
On Fri, Dec 11, 2015 at 12:00:57AM +0100, Rick van Rein wrote:
> I was thinking of client-side tokens, not the KDC.

There's no need for KITTEN to be involved in making Kerberos clients use
a token.

> > I'd be much more interested in working on a DANE-based mech_dh
> > replacement than in working on putting a KDC in a token.
>
> I have a student working on that now :) and will send a project
> description/proposal to at least MIT krb, and perhaps also Kitten,
> sometime soon.

Oh, that's interesting.

> > Such a mech
> > could have Kerberos-compatible principal naming and even attribute
> > certificates to match authorization-data.  Being PK- and DNSSEC-based
> > would mean cross-realm functionality would be present from the get-go,
> > and it'd mean that HW tokens would be meaningful from day one as well
> > (well, as meaningful as they are with any PK today).
>
> PKINIT makes PK usable already, so I'm not sure why you bring
> DNSSEC/DANE in here?  Do you want to improve on the cryptographic
> strength of the initial password to protect AS?

DNSSEC/DANE is to get a PKI.  DNSSEC is a PKI, a true hierarchical one,
and one using domainnames as issuer and end entity names.  The WebPKI is
not really hierarchical, doesn't deal well with domainnames, and has
other shortcomings.  Using DNSSEC/DANE means instant "PKCROSS" for a
modern mech_dh.  The key is to staple DNS responses that contain all the
necessary RRs, with the trust chain mostly as additional RRs.

Nico
--

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

Re: [kitten] New EncTypes?

Henry B Hotz
In reply to this post by Rick van Rein (OpenFortress)

> On Dec 10, 2015, at 3:00 PM, Rick van Rein <[hidden email]> wrote:
>
> Hi Nico,
>
> I was thinking of client-side tokens, not the KDC.
>
> Symmetric keys reside on two ends, but the client will be much weaker in
> its protection than the KDC; a reason for using PKCS #11 on the client
> end is to uplift that level (and have better entropy than a password
> supplies).  That would be an improvement even if the KDC was not changed
> at all.  I agree that hardening the KDC can be pretty much comparable to
> hardening an HSM.
>> Hardware tokens make a lot more sense for PK-based protocols.  If you
>> really want HW tokens, then Kerberos is not for you.
>
> Yes and no... it's not a one-dimensional choice between PK and KRB5.

There’s no reason you can’t build a smart card that will do AES on supplied data once unlocked with a PIN.  Keys importable, but not exportable. I think the right comparison is to a keytab, so it’s not even that radical.

Agree that X.509/PKIX has a lot of distracting complexities (I’m being polite), and DNSSEC is a better PKI for us. I like the possibility of a more scalable cross-realm alternative. The existing one is good for small scale, like single-hop relationships.

Is there actually interest in a HSM/KDC combination? I toyed with the idea once. . .

More to the point of the thread, I’m not sure any of these things necessitate EncType or protocol changes. Defining a relationship between DNSSEC and PKINIT/PKCROSS is a new area. While we’re at it, could we define the user’s Principal to be a functional email address in DNSSEC and make signed/encrypted email usable? I could argue that this is the way things are supposed to work!



Personal:  [hidden email]
Business: [hidden email]

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

Re: [kitten] New EncTypes?

Benjamin Kaduk-2
In reply to this post by Nico Williams
On Wed, 9 Dec 2015, Nico Williams wrote:

> On Wed, Nov 18, 2015 at 04:20:41PM -0800, Henry B (Hank) Hotz, CISSP wrote:
> > It seems to be time to do housecleaning on algorithms selections. Is
> > anyone interested in adding a new enctype to Kerberos?
>
> Luke's working on AEAD enctypes.
>
> > Why (else)?  Speaking strictly for myself, I’d like to see a
> > mandatory-to-implement enctype that shares *nothing* with the current
> > aes-sha1-hmac stuff. I’m speaking purely strategically and not from
> > any mathematical suspicion of weakness. If someone discovers something
> > fundamentally wrong with the math behind SHA1 or AES, then it might
> > take out SHA2 or Camellia as well.
>
> It's hard not to share AES.  Nowadays CPUs can do AES in constant time,
> very fast, in hardware.  That's hard to pass up.
>
> Yes, AES in software is terrible for security, and an alternative would
> be nice for systems that don't have AES HW.
You don't see potential in a chacha/poly scheme?  Not that I'm
volunteering to write the draft, mind you...

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

Re: [kitten] New EncTypes?

Benjamin Kaduk-2
In reply to this post by Henry B Hotz
On Thu, 10 Dec 2015, Henry B (Hank) Hotz, CISSP wrote:

>
> More to the point of the thread, I’m not sure any of these things
> necessitate EncType or protocol changes. Defining a relationship between
> DNSSEC and PKINIT/PKCROSS is a new area. While we’re at it, could we
> define the user’s Principal to be a functional email address in DNSSEC
> and make signed/encrypted email usable? I could argue that this is the
> way things are supposed to work!

I have not been following particularly closely, but I thought there was a
lot of trouble finding a reasonable way to present email addresses in the
DNS and get continuity of keying -- the DNS administrator may not have a
good connection to where the user's key gets set, etc..

I forget where this discussion was going on, though ... maybe perpass,
though that doesn't quite feel right.

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

Re: [kitten] New EncTypes?

Stephen Farrell


On Fri Dec 11 04:30:52 2015 GMT, Benjamin Kaduk wrote:

> On Thu, 10 Dec 2015, Henry B (Hank) Hotz, CISSP wrote:
>
> >
> > More to the point of the thread, I’m not sure any of these things
> > necessitate EncType or protocol changes. Defining a relationship between
> > DNSSEC and PKINIT/PKCROSS is a new area. While we’re at it, could we
> > define the user’s Principal to be a functional email address in DNSSEC
> > and make signed/encrypted email usable? I could argue that this is the
> > way things are supposed to work!
>
> I have not been following particularly closely, but I thought there was a
> lot of trouble finding a reasonable way to present email addresses in the
> DNS and get continuity of keying -- the DNS administrator may not have a
> good connection to where the user's key gets set, etc..
>
> I forget where this discussion was going on, though ... maybe perpass,
> though that doesn't quite feel right.
>

DANE

S.

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

Re: [kitten] New EncTypes?

Rick van Rein (OpenFortress)
In reply to this post by Henry B Hotz
Hi Henry,

> I like the possibility of a more scalable cross-realm alternative. The
> existing one is good for small scale, like single-hop relationships.
>
I will put it up soon, and sounds like I should also post that MIT krb5
project here.  Writing to do for me...

> Is there actually interest in a HSM/KDC combination? I toyed with the
> idea once. . .
>
It's a design alternative I'm looking into for InternetWide.org identity
management.  So, I'm also toying with it and thought when discussing new
enctypes it would be good to bring up as a potential avenue.

As for email-style names, interesting, we generally look at the concept
of a NAI, RFC 7542.  The difference being, it's not necessarily possible
to send email to this [hidden email] style address.  We defined
general patterns for those as well, http://donai.arpa2.net/selector.html

Cheers,
 -Rick

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

Re: [kitten] New EncTypes?

Jeffrey Altman-2
In reply to this post by Benjamin Kaduk-2
On 12/10/2015 11:28 PM, Benjamin Kaduk wrote:
>
> You don't see potential in a chacha/poly scheme?  Not that I'm
> volunteering to write the draft, mind you...

I would like to see a chacha/poly enctype but I'm not going to fund its
development in the short term.

It would be good to have a non-AES enctype in our back pocket even if we
aren't using it regularly today.

Jeffrey Altman



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

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] New EncTypes?

Simo Sorce-3
On Fri, 2015-12-11 at 11:52 -0500, Jeffrey Altman wrote:

> On 12/10/2015 11:28 PM, Benjamin Kaduk wrote:
> >
> > You don't see potential in a chacha/poly scheme?  Not that I'm
> > volunteering to write the draft, mind you...
>
> I would like to see a chacha/poly enctype but I'm not going to fund its
> development in the short term.
>
> It would be good to have a non-AES enctype in our back pocket even if we
> aren't using it regularly today.

MIT implements Camellia ...

Simo.

--
Simo Sorce * Red Hat, Inc * New York

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

Re: [kitten] New EncTypes?

Henry B Hotz
IIUC Camillia is based on the same math as AES. I was advocating for something unrelated. I think chacha/poly qualifies, so I’m interested.


> On Dec 11, 2015, at 9:12 AM, Simo Sorce <[hidden email]> wrote:
>
> On Fri, 2015-12-11 at 11:52 -0500, Jeffrey Altman wrote:
>> On 12/10/2015 11:28 PM, Benjamin Kaduk wrote:
>>>
>>> You don't see potential in a chacha/poly scheme?  Not that I'm
>>> volunteering to write the draft, mind you...
>>
>> I would like to see a chacha/poly enctype but I'm not going to fund its
>> development in the short term.
>>
>> It would be good to have a non-AES enctype in our back pocket even if we
>> aren't using it regularly today.
>
> MIT implements Camellia ...
>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
>
> _______________________________________________
> Kitten mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten


Personal:  [hidden email]
Business: [hidden email]

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