Concerns about the Response_set interface

[Sam Hartman]

hi.  It's great to see that we're looking at more modern preauth
interactions.  I aggree that the prompter interface is showing its
age. I also believe that being able to request a number of interactions
at once is valuable as is requesting interactions that are
hardware-based.

This review at least feels like it's being presented in a vacuum and I
think that both the design and review would benefit significantly from
being stuck in some significant context. I think that's true both in
terms of what we're doing with other parts of the system along with how
this interface will be used.

Here are my concerns in more detail:

1) I think we need to understand how we will handle response_sets in the
GSS-API before we can evaluate the design of a krb5 API. With the advent
of iakerb and gss_acquire_creds_with_password we're seeing more interest
in GSS applications wanting to obtain initial credentials. The GS2
bridge now in Cyrus SASL will attempt to acquire initial creds. In the
Moonshot effort we're coming to a fairly strong consensus that
applications may need to play more of a role in GSS credential
acquisition; that's likely to mean kerberos sees more apps wanting to
manipulate initial credentials.

So, I think that some day, this sort of interface is going to need to
appear in the GSS land.  I am not asking that we implement that now. I'm
not even asking that we fully design that now.  I am asking that we
understand how this is going to work with GSS enough to validate the
architecture.

I'm skeptical of this architecture aligning well with GSS
interfaces. The memory management seems very C-specific. It seems like
it's going to be very difficult to proxy this mechanism through a GSS
proxy. We've already said in the gss_export_cred discussion that the
proxy will want to deal with all sorts of credentials. Eventually it may
need to acquire them.

2) Interoperability of credential acquisition is important. There are
many many applications that get initial credentials. It's critical that
we not design things that make it easy for sssd and that don't work for
the rest of the world.
A couple of things fall from this:

* Many applications will end up needing to implement response set
  interfaces.

* It's strongly desirable that we minimize what gets done in the
  response set.

* In the specific case of OTP, we do not want to build hardware
  interaction into every application that supports credential
  acquisition. Interacting with OTP tokens is going to be tricky and
  fiddly, so we need it to be reusable. That probably means it cannot be
  on the application side of the response set interface. Folks involved
  in the OTP plugin have claimed that there's not a good interface for
  interacting with OTP tokens. Pushing this over to applications and
  ending up with a situation where what hardware token you can use
  depends on what application you use to acquire credentials seems
  really bad and seems like something the Kerberos community needs to stop.

For these reasons, I think it would be better to review this
architecture along with a specific non-trivial proposal for using this
architecture. I believe that should be OTP. I'd hate to be in a position
where we're reviewing the OTP client plugin integration and we conclude
that response_sets are the wrong approach for that and something else is
needed.



3) It seems naive to assume all data is allocated by the library. I can
imagine situations where the response involves allocating data.


Those are my initial comments.  I've read a number of messages in the
thread from last week but not all of them.  I generally agree with many
of the comments Nico raised while I have sympathy for some of the issues
Nathaniel brings up.


I think that significantly more discussion is required on this
interface.
I appreciate that there are some important and timely issues here and am
delighted that we're stepping up to address them!