Re: please cast your vote: do we need a standard way
Martin Rex <Martin.Rex <at> sap.com>
2008-10-10 16:32:31 GMT
Larry Zhu wrote:
> I spoke figuratively. Suppose I want to supply alternative
> credentials/keys (not the password), then I do not have a
> standard way to do that.
GSS-API standardizes _only_ a simple way of _anonymous_authentication_.
When using GSS-API, there is no standardized way to acquire credentials
by password, credentials can only be acquire by name, implying that
(pre-existing) credentials are merely accessed, not created.
Creation and destruction of credentials is a local matter.
A password for an anonymous credentials is IMHO a misconception.
If the underlying gssapi mechanism requires and explicit,
password-protected credential in order to create or obtain an
anonymous credential, then this ought not to be confused --
this is then no password for the anonymous credential.
If two distinct principals userA <at> REALM1 and userB <at> REALM1 using distinct
Kerberos passwords want to acquire an anonymous credential
WELLKNOWN/ANONYMOUS <at> REALM1, then I assume that each one would have
to supply his very own password (if any) in a non-standardized
fashion, rather than both supplying a (wellknown?!?) password
of the principal "WELLKNOWN/ANONYMOUS <at> REALM1".
The bottom line is: GSS-API does *NOT* define anonymous credentials
and so does neither standardize nor describe how to acquire them.
(btw. would SSPI prompt the user to enter the password for
WELLKNOWN/ANONYMOUS <at> NTDEV or lzhu <at> NTDEV?)
Thinking about it, the recommended portable use of gssapi with
the standardized used of "anonymous authentication" is likely
to result in the partial-anonymous authentication, because
it means that gss_init_sec_context() is called with a NULL
credentials handle (meaning "use default credential"),
and requesting the anonymous authentication context attribute.
Although it sounds somewhat counter-intuitive -- one could argue
that a partially anonymous security context resulting from
the use of the default credential should actually be indicated
with the return of the GSS_C_ANONYMOUS_FLAG.
As was discussed, a fully-anonymous authentication with Kerberos
may require the use of an explict credential created via PKINIT,
and some yet unspecified means to acquire an explicit credentials
handle (gss_cred_id_t) to this credential in order to pass it
to gss_init_sec_context(). The only currently GSS-API standardized
way to acquire a credential handle to an existing credentials
(created in a implementation defined way) is by name, by mechanism
or a combination of both.
PS: Larry, the quoted text in your last Email was concatenated into one
super-long single line, all linefeeds removed (at least in the ASCII
part that I'm using.
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov