On Mon, Sep 13, 2010 at 07:18:07PM +0200, Luke Howard wrote:
> > Not really, no, not if the defer things involve bits that need to be
> > carried in context tokens.
>
> It wasn't my understanding that this was the case. But, I guess, I
> didn't provide you with enough context (pun not intended).
Er, I wasn't thinking very specifically of EAP, but more generally. Now
I see that you're correct, you could defer the attribute resolution.
- In the case of RFC4121 there's nothing that the acceptor can request
of the initiator nor Kerberos infrastructure as there's at most one
context token round-trip.
- In the case of EAP the acceptor _can_ request additional data from
the AAA server, because in this case the infrastructure is on the
acceptor-side. And because the infrastructure is on the
acceptor-side the acceptor could request that additional data from
the infrastructure any time it wants, including long after the
security context is fully established.
- In a multi-round-trip variant of RFC4121 the acceptor could request
additional data from the initiator and/or Kerberos infrastructure.
But because in this case the infrastructure is on the initiator side,
the acceptor may not be able to reach that infrastructure after the
security context is fully established.
In other words, the best we can do while staying generic (remember, that
'G' in GSS-API stands for 'generic') is to have the acceptor application
provide the set of desired initiator name attributes up front. And for
that, I believe the best vehicle we have is the acceptor credential
handle.
Of course, there's no need to be generic for every feature. So,
thinking of EAP specifically, I realize that it'd be perfectly OK to
defer attribute resolution.
> > I would prefer a credential option because that's the only thing that's
> > like a "security context template" that we have now. If you wanted to
> > tell Cyrus SASL that you need some set of attributes from the peer, then
>
> Yes, I'm agreeing with you now.
Cool.
> > In a version 3 of the GSS-API we might well have a security context
> > template object. Adding such an object seems to me to be much more
> > significant a change to the API than is the addition of name and/or
> > credential attributes.
>
> Call me when it's done? ;-)
Heh. No one is working on GSS-APIv3, to my knowledge. I was, in my own
time, prior to Oracle CIC, but I have stopped. But even if I was, I
think I might still be loathe to making changes that would have
significant impact on how libraries and applications deal with the
GSS-API.
Nico
--
|