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:[email protected]] 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...
