On Mon, Nov 21, 2011 at 9:45 AM, Sam Hartman <[email protected]> wrote: > Hmm. There's a sort of wild carding present in gss-eap today. In > particular, the EAP server is only required to perform channel binding > on parts of the name present in the EAP channel binding data from the > initiator. so, for example, if the hostname component is absent, any > hostname may be supplied by the acceptor. > I think this is OK.
IMO it's OK. The API needs a way to represent this though. I'm not sure that this is an important feature -- it'd be less important if we had proper credential sets. But let's sketch it: - Add a new name-type called GSS_C_NT_HOSTBASED_SERVICE_PATTERN with the same syntax as host-based service names, but that allows either or both the service and hostname to be wildcarded. - Mechanisms that support this will indicate it through GSS_Inquire_names_for_mech(). But I think it'd be preferable instead to say that any mechanism which supports target_name == GSS_C_NO_NAME supports wildcarding since the initiator can take the acceptor's chosen name and match the pattern against it. - What to do when GSS_Canonicalize_name() is called on a non-MN of that name type? - When a host-based service name pattern is used as a target name in GSS_Init_sec_context() the acceptor will pick a credential whose desired_name matches the given pattern, else it will fail. The initiator application can see that name by calling GSS_Inquire_context() on the established sec context (or when it's PROT_READY). - Alternatively the initiator use GSS_C_NO_NAME as the target_name and the acceptor uses patterns for credential acquisition so as to have credentials only for the desired sub-set of acceptor names. Hmmm, the complication here is that not all mechanisms can support this mode. If the goal is to wildcard the host portion then I'd rather say that the acceptor must have credentials only for its service (while still using GSS_C_NO_CREDENTIAL) and then the initiator uses GSS_C_NO_NAME for the target and checks the result via GSS_Inquire_context(). Nico -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
