On Thu, Apr 05, 2007 at 05:52:52PM -0400, Olga Kornievskaia
wrote:
> Is PKU2U meant to be a GSS API mechanism or a stand
alone security
> protocol? The abstract seems to imply that pku2u could
be a stand alone
> protocol. However, the 1st sentence of the Section 5
says that pku2u
> "can only be used in conjunction with
GSS-API".
GSS mechanisms can be stand-alone too, I suppose. PKU2U has
got to be
intended to be a standards-track GSS-API mechanism, else why
are we
here?
> In Section 5,
>
> The syntax of the initial context establishment token
follows the
> initialContextToken syntax defined in Section 3.1 of
[RFC2743].
> PKU2U is identified by the Objection Identifier (OID)
id-kerberos-
> pku2u.
>
> id-kerberos-pku2u ::=
> { iso(1) org(3) dod(6) internet(1) security(5)
kerberosV5(2)
> pku2u(7) }
>
> Subsequent context establishment tokens MUST NOT be
encapsulated in
> this GSS-API generic token framing.
>
>
> First, I hope that the 1st sentence refers to
"tokens" not just the 1st
> (AS_REQ) token. As its written, it says that AS_REQ
token is framed but
> the AS_REP token is not which doesn't make sense.
No, it *does* make sense. RFC2743 only requires the
pseudo-ASN.1 DER
header on the initial context token. It does not require it
on any
other tokens at all.
RFC1964 went beyond this and required the use of that header
on all of
the Kerberos V GSS mechanism's context and per-message
tokens. We all
recognize that there was little or no point to this, so when
we were
working on RFC4121 we wanted to dispense with that header on
all but the
initial context token (that one being required by RFC2743)
and settled
for not having that header on per-message tokens but keeping
it on all
context tokens (primarily because of packet inspection tools
that are
used to them having that header, as I recall).
> Second, what does the "subsequent context
establishment tokens" refer
> to? AP_REP/AP_REQ or a something else (ie. , new pku2u
sessions)?
PKU2U's context token exchanges look like this:
I: <RFC2743 header> AS-REQ
A: AS-REP
I: AP-REQ
A: AP-REP
Here the first one is the "initial context
establishment token" and the
subsequent three tokens are ""subsequent context
establishment tokens."
> Furthermore, there shouldn't be any unframed tokens in
GSS-API mechanism.
This is incorrect.
> I propose to remove this sentence from the draft. What
would be left is
> the description how to frame context establishment
tokens
> (AS_REQ/AS_REP) and then the rest are treated as
per-message token
> according to rfc4121.
You might argue that if you'd like to build PKU2U as a
stackable
mechanism that stacks on top of RFC4121 *then* having the
RFC2743 header
on the AP-REQ/AP-REP tokens in the PKU2U spec would help
keep your
implementation simple. As a proponent of stackable
mechanisms I tend to
agree, but because this stackable mechanism in particular
would be
stackable only on top of RFC1964/RFC4121 it would be OK for
the
implementation to know to remove the header on output/insert
the header
on input.
[Note to skeptics: yes, such a stackable mechanism would
need a special
interface by which it could turn acquire a CREDENTIAL HANDLE
for the
Kerberos V mechanism using a Ticket, ticket session key and
ancilliary
data. In Solaris we have gss_acquire_cred_with_password();
we could
easily add gss_acquire_cred_with_ticket()...]
I feel loath to perpetuate the mistake made in RFC1964 of
adding that
header that had been intended only for the initial context
token to all
tokens.
Nico
--
_______________________________________________
Kitten mailing list
Kitten lists.ietf.org
https:/
/www1.ietf.org/mailman/listinfo/kitten
|
