Or, 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.
For 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.
GSS-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.
Those 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.
