2 ms·
Agreed. It can be fun and/or sometimes necessary to roll your own, but, at least get it reviewed by someone who knows what they're doing - anyone on the IETF Ki
by lukeh 13y ago
Agreed. It can be fun and/or sometimes necessary to roll your own, but, at least get it reviewed by someone who knows what they're doing - anyone on the IETF Kitten working group, for example (for a SASL mechanism).
- lukeh 13y agoOr, use RFC 4121. It's not just for Kerberos: GSS EAP (Moonshot), BrowserID (Persona), and SAML EC all use it for message integrity and privacy. And those specifications were all written by smart people (save for myself, at least) who could have rolled their own if they wanted to.
- tptacek 13y agoFor the love of almighty and merciful God please do not use GSSAPI. MAC-then-encrypt? CRC checksums? All-zeroes IV? CBCMAC? This stuff died in the '90s for a reason.
- lukeh 13y agoGSS-API says nothing about any of the things you mention, it's an abstract standard (like SASL) that can be profiled for many different authentication and message integrity/confidentiality systems. The DES-based Kerberos GSS-API mechanism you're thinking of should be dying out by now. Granted, RFC 3962 does MAC-then-encrypt. This is being addressed in draft-ietf-kitten-aes-cbc-hmac-sha2.
- tptacek 13y agoThose are all things I took out of 3962. But furthermore, I'm now even more confused by your recommendation. If it's a metastandard (which has always been the rap on stuff like SASL), how does it help them design good crypto? I can't see any reason in the world to adopt GSSAPI. I strongly recommend that nobody else do so.
- lukeh 13y agoI wasn't recommending GSS-API per se, just the message protection services from 3961/4121. It was just a suggestion. Feel free to roll your own!