On Fri, Dec 16, 2011 at 2:01 AM, Jim Schaad <[email protected]> wrote:
> 5.  If I get to this point, have I already selected the credential that I
> will be using with the EAP server, or I have just gotten to the point of
> saying that I will be using one of a set of credentials?  This is an LOA
> question.  I will have already selected the realm that I am going to be
> authenticated against since I know that goes out in the first GSS-API/EAP
> message.  I also understand that by selecting a realm, I may have restricted
> the set of possible LOAs that I can be dealing with.  Should my protocol
> allow for some type of re-start of negotiation if a different LOA is needed?

It's always nice to be able to restart authentication if it fails.

SSHv2 supports multiple userauth attempts, but not multiple key
exchange attempts, which means that SSHv2 with GSS key exchange (an
option where we do GSS and key exchange in one go) is painful when GSS
fails.

I strongly recommend that authentication be retriable.  I believe
HTTP/Negotiate is (you're already using HTTP/1.1 if you're using
HTTP/Negotiate with multi-round-trip mechanisms anyways!).

Also, I don't think you'll always know the realm of the target a
priori.  Certainly not in the case of HTTP, not unless the realm
directly matches the server's DNS domain.

> I assume that would need to be a total re-start of the GSS-API/EAP
> negotiation at a minimum although I could leave up the TLS session.

Yes, it'd be a restart of GSS, but there'd be no need to restart TLS,
unless the application protocol really can't deal with the GSS
restart.

> 6.  Should I be setting up some type of negotiation in my protocol to allow
> for a different GSS-API mechanism to be selected?  I.e. if one is within a

If we're talking about HTTP/Negotiate well, you already have SPNEGO for that.

> single company one could use the Kerberos GSS-API rather than going with the
> EAP version.  Would be think this is of importance or can I just restrict to
> using the one GSS-API mechanism and be done with it?  Can this type of
> negotiation be done within GSS-API?  I don't remember seeing anything of
> this sort but that does not mean it does not exist.  My understanding was
> that it amounted to configuration information on the client side.

SPNEGO is a pseudo-mechanism that negotiates mechanisms, so that's "within GSS".

Some application protocols can do this negotiation themselves.  For
example: SSHv2.

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

Reply via email to