Subject: [Ietf-krb-wg] FAST - Authentication Sets - REQUIRED/REQUISITE/SUFFICIENT/OPTIONAL

From: "Srinivas Cheruku" <[email-masked]>
Date: Tue, 21 Jul 2009 12:02:44 +0530

Sam,

Just an idea.

Using JAAS, in a authentication stack, we can specify option on a
loginmodules as REQUIRED/REQUISITE/SUFFICIENT/OPTIONAL.

Maybe, we can use the same concept using authentication sets as these are
similar to authentication stacks can contain more than one pa-data items and
we can say whether each paitem is required/requisite/sufficient/optional. I
think this might be useful when supporting more authentication methods using
FAST.

Thanks,
Srini

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Thu, 30 Jul 2009 05:50:38 -0400

The required/requisite/optional/sufficient distinction was first
introduced in PAM, not JAAS.

I can't say that I've had great success with that model in PAM;
Linux-PAM has tended to move away from it because it does not tend to
express the right relationships for automatically generated real-world
configurations.

For those not familiar with either JAAS or PAM, here is a brief overview:

* requisite: if this fails, stop right there, no more interactions.
* required: If this fails, eventually the authentication will fail, but go through the motions
* sufficient: If this succeeds and no previous required modules fail, stop right there and succeed
* optional: If this fails, who cares!

Something has to succeed (although it can be an optional module) for
authentication to succeed.

For fast factors that provide mutual authentication and the like, the
difference between required and requisite will be lost.  It's not
entirely clear to me that optional has much use in Kerberos as part of
an authentication set; optional padata like etype-info2 (optional in
that it does not directly contribute to authentication, not optional
in presence) is already supported.

I think sufficient  is also already supported: the KDC could return a premature as-rep if it likes.

Also, this is a post-last-call suggestion.

So, while we may need to revisit this later, I don't think we have a
good enough handle on how to integrate such a concept or on whether it
is needed.  I do not believe that delaying the document to do that
design would be valuable at this point.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg