directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <kai.zh...@intel.com>
Subject RE: About Haox project
Date Sat, 27 Dec 2014 09:14:11 GMT
Sorry I should have mentioned it as "Kerberos cryptosystem", as RFC3961 says. Thus it could
avoid the confusion here since crypto often means encryption crypto.
http://tools.ietf.org/html/rfc3961.html

To clarify further and also in case it helps.
1. A Kerberos cryptosystem may take care of the following aspects:
1) How user plain password to be transformed into Kerberos encryption key;
2) How random bytes to be transformed into Kerberos encryption key;
3) How Kerberos message to be reorganized into cipher buffer to be encrypted, like padding,
adding confounder, and etc.; similarly for decryption;
4) How Kerberos message to be computed for a checksum and verified against the checksum.

2. MIT Kerberos supports encryption types as the following doc tells. The kerb-crypto in Haox
is totally following it.
http://web.mit.edu/Kerberos/krb5-1.11/doc/admin/conf_files/kdc_conf.html#encryption-types


>>That's not that simple. Of course, we should support MIT based configuration, but
you also have to consider those admin who have to install a kerberos server and don't know
about tjose files : they most certainly expect the product we deliver to take care of the
config without having to deal with .conf files...
Yes I agree. We'll need a JIRA entry to fully discuss and document how we would support configuration,
how we can simplify the administration work and avoid complexities here. 

Regards,
Kai

-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com] 
Sent: Saturday, December 27, 2014 3:39 PM
To: Apache Directory Developers List
Subject: Re: About Haox project

Le 27/12/14 02:36, Zheng, Kai a écrit :
>
>>> I wanted to build a ASN/1 compiler (see 
>>> http://svn.apache.org/repos/asf/labs/dungeon/)
>>> Implementing a new Codec requires a huge effort, even for me.
> It's very interesting about the compiler. Actually it was in my mind to support such
compiler for haox-asn1 library, enabling to compile an ASN1 definition module (like krb5.asn1)
and automatically generate all the necessary Java types (like Kerberos codec classes), and
we don't even bother to code them manually.  Yes it's hard, huge effort is involved, not easy
for me either.

The major pb with this compiler is that we have to be able to process teh full ASN.1 grammar,
and it's quite complex. We also have to think about the generator, and we don't have only
one target : DER/CER/BER is simple, XER is probably useless, but PER is mandatory and this
is really the complex one. All in all, this is not simple...

>
>>> I would rather first check what Bouncy Castle has to propose in this area. I'd
be really careful here, implementing some crypto amgorithm is seriously complex, and require
a lot of care.
> Sorry I'm confusing and have to be clear here. When I mentioned "implement all the encryption
types and checksum types that MIT Kerberos supports, like DES, DES3, AES, RC4, CAMELLIA",
I mean we need to implement the Kerberos encryption types and checksum types which are often
mentioned as Kerberos crypto. Such crypto isn't the one in JCE neither any in BC, where only
covers concrete encryption algorithms. Kerberos crypto is based on concrete encryption algorithms
and implementations, but would never bother to define and implement any encryption algorithms
itself.
>
> Yes we could rely on the Kerberos crypto implemented in JRE, as existing ApacheDS Kerberos
implementation does. The problems are: 1) JRE doesn't expose the functionalities fully and
is very limited; 2) It's not complete and we can't guarantee full interoperable with MIT Kerberos
and MS-AD; 3) Relying on JRE means we'll never be able to go beyond that, if the corresponding
support isn't available in JRE, then we'll stop there. You might agree that many modern Kerberos
features are just not available yet.
>
> In my view we have to tweak it for ourselves, that's why I spent so much time on it.
The framework originates the one from MIT Kerberos and is very flexible, say once a new encryption
type is up then it's easy to add it accordingly so we are updated! The support is complete
and all the ones provided in MIT Kerberos are done. I'm confident with it, basically I would
think it's the core part that's essential for a Kerberos implementation. Without it, maybe
it's fine for us to just replace the Kerberos codec part based on existing Kerberos implementation.
Yes we must be careful with the codes. I would be very happy for your review of it and make
it strong enough. 

Ok, seems like I have to do my homework in this area ;-)


>>> has also to be considered is the configuration part, and integration with Studio.
> Yes agree. Regarding Kerberos configuration either in client side (krb5.conf) or server
side (kdc.conf), I guess we'd better make it compatible with MIT Kerberos so that administrators
won't have to learn about it. Also in our documentation for simple we would just say "please
reference MIT Krb5 doc" as we're going the same way. A contributor is work on it and will
commit the codes once the codebase is imported.
That's not that simple. Of course, we should support MIT based configuration, but you also
have to consider those admin who have to install a kerberos server and don't know about tjose
files : they most certainly expect the product we deliver to take care of the config without
having to deal with .conf files...



Mime
View raw message