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
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
