Subject: [abfab] GSS EAP and NegoEx

From: Luke Howard <[email-masked]>
Date: Wed, 20 Jun 2012 14:57:18 +1000

I'm going to propose the format of a NegoEx metadata exchange for GSS EAP. NegoEx allows an authentication mechanism to be negotiated using factors beyond mutually supported mechanisms; it optionally adds a pair of metadata messages exchange by each negotiable security mechanism (I'm liberally paraphrasing from draft-zhu-negoex here; read that for the details).

The purpose of the metadata exchange is to allow the initiator to validate the EAP server's certificate before committing to context establishment.

The format of the metadata tokens is identical to the GSS EAP tokens, except the outer token type is TOK_TYPE_INITIATOR_META_DATA (0x0603) or TOK_TYPE_ACCEPTOR_META_DATA (0x0604). GSS_Query_meta_data on the initiator emits the first; on the acceptor, the latter. Each outer token contains a set of inner tokens; a convention is that inner token types with the 0x1000 bit set are reserved for metadata.

The following inner tokens are defined:

#define ITOK_TYPE_INITIATOR_NAME_MD     0x00001000 /* anonymised initiator name */
#define ITOK_TYPE_SERVER_SHA256_MD      0x00001001 /* EAP server certificate hash */
#define ITOK_TYPE_SERVER_SUBJECT_MD     0x00001002 /* EAP server subject name */
#define ITOK_TYPE_SERVER_CERT_MD        0x00001003 /* EAP server certificate */

The first, ITOK_TYPE_INITIATOR_NAME_MD, allows the initiator to indicate its realm to the acceptor. This goes in the clear, but it's the same data that you see later in an EAP identity request. (Remember that NegoEx integrity protects the entire exchange.) The initiator only sends this if it does not have any other means to authenticate the server (i.e. an existing trust anchor).

The acceptor parses the initiator metadata token in GSS_Exchange_meta_data. If there is no ITOK_TYPE_INITIATOR_NAME_MD, and no other critical tokens it does not understand, it does nothing.

Otherwise, the acceptor begins a EAP exchange with the AAA server selected for the identity indicated in ITOK_TYPE_INITIATOR_NAME_MD. The exchange will not complete, obviously, because the acceptor does not have the initiator's credential; however, if it gets to the point where the EAP server returns a certificate (EAP-[T]TLS), then that is saved. The result of the authentication is discarded. This is similar to wpa_supplicant in "probe" mode.

If a certificate was returned, the acceptor may return the SHA-256 certificate hash (in ITOK_TYPE_SERVER_SHA256_MD) and the subject name (ITOK_TYPE_SERVER_SUBJECT_MD). It may optionally also return the certificate (ITOK_TYPE_SERVER_CERT_MD).

This doesn't add any round trips to the authentication exchange (if the initiator uses an optimistic token), but it does allow the initiator to validate the server before committing to an authentication, perhaps choosing a different mechanism if preferable. NegoEx implementations that support surfacing of metadata via UI may display the certificate hash and allow the user to accept the certificate for this or all authentications. It does add a number of round trips to the AAA server, which may impact performance, so the initiator should only request this if it has no other way to authenticate the server.

I have this implemented on GSS/SSPI, although I'm yet to do anything useful because there's no UI integration yet.

-- Luke