Subject: [abfab] GSS EAP: Acceptor Name all the time

From: Sam Hartman <[email-masked]>
Date: Fri, 18 Nov 2011 06:55:35 -0500 (EST)

Jim has requested that the acceptor always return an acceptor name
token to the client even if the client sends an expected acceptor name
token to the acceptor.  The idea is that if the client sends something
like smtp the acceptor could return [email-masked].

The advantage here is that the client gains a more complete form of the acceptor name.

In the meeting today I said there were no disadvantages besides a few octets.
Turns out that's not quite true.
The client now needs to confirm that the received name is acceptable.
Implementing that is a tad tricky but certainly doable.

I support this change but would like to call for comments.

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 18 Nov 2011 21:46:09 +0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sam Hartman
> Sent: Friday, November 18, 2011 7:56 PM
> To: [email-masked]
> Subject: [abfab] GSS EAP: Acceptor Name all the time
> 
> 
> Jim has requested that the acceptor always return an acceptor name token
> to the client even if the client sends an expected acceptor name token to
the
> acceptor.  The idea is that if the client sends something like smtp the
> acceptor could return [email-masked].
> 

While it is true that the client can confirm that the received name is
acceptable, I think that for the most part this could be considered to be a
NOP as the name returned SHOULD be a more detailed version of the name the
client sent up.  That is if the client asks for "smtp" then the server MUST
NOT return "[email-masked]" as this would be something that would
never be expected.

If the client does not do the validation, then it can send its version of
the name as part of the channel bindings and let the EAP server worry about
the comparisons.  IN that case it will be no worse than it is today.

Jim

> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 20 Nov 2011 13:46:22 -0800

Another advantage of this proposal is for re-connections.  It would be
possible to connect to an arbitrary server the first time and be more
specific about the server the next time you connect as you might have cached
some tokens for doing the reconnect.  You want to know who to reconnect to
the second time around.

Jim

> Sent: Friday, November 18, 2011 3:56 AM
> To: [email-masked]
the

---

From: Nico Williams <[email-masked]>
Date: Sun, 20 Nov 2011 15:54:10 -0600

I like the ability to canonicalize target names during security
context establishment, particularly when target_name == GSS_C_NO_NAME.

The idea that a name could be wildcarded is neat, but not really
necessary since the client could just use target_name == GSS_C_NO_NAME
then do the matching on the actual target name (obtained with
GSS_Inquire_context()).  Ah, but if the acceptor is using
GSS_C_NO_CREDENTIAL and has credentials for lots of names including
host-based service names for lots of services... then the selected
target name may not match the initiator's desired service name.

To add wildcarding to the API would require some additional work at
the API level (mainly in the form of new name types, i think), but it
could be done.  I'd be OK with it.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Nov 2011 10:45:48 -0500

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> To add wildcarding to the API would require some additional
    Nico> work at the API level (mainly in the form of new name types, i
    Nico> think), but it could be done.  I'd be OK with it.

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.

---

From: Nico Williams <[email-masked]>
Date: Mon, 21 Nov 2011 10:09:11 -0600

> hostname may be supplied by the acceptor.

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
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 Nov 2011 11:29:38 -0500

OK.  Well, if you have any concerns about the text currently in the
draft please raise them.  As best I understand what you're saying what
the draft says is fine.

--Sam