Subject: Comments on draft-williams-gssapi-v3-guide

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 13:09:10 -0400

In the section on portability considerations, you propose using
runtime configuration at compile time in order to perform compile-time
feature tests.  This practice is problematic for cross-compiled
environments.  I think we may want to consider cases wher compile time
tests for at least some features are appropriate.

Do we really need an IANA registry for names of APIs in the GSSAPI?
It seems like we expect such apis to be defined through standards
action.  Do we expect it to be hard enough to manage that we get
significant value from an IANA registry?

I do believe we want an IANA registry for error values and possibly
for minor status.

Here are some questions I think we should consider with regard to
GSSAPI v3:

1) To what extent are we trying to produce a single API document
   incorperating all the new APIs and to what extent are a bunch of
   smaller documents appropriate?

2) To what extent do we want to encourage V2 implementations to adopt
   backward-compatible parts of V3?

3) What parts of what we propose are actually backward incompatible?

--Sam

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 Oct 2004 12:40:39 -0500

> tests for at least some features are appropriate.

I thought a runtime facility would be a good way to get started, then we
could consider compile-time facilities, for which I'm not sure there
will be demand.  We should seek consensus on this.

Certainly some GSS-APIv3 features, those that define new constants,
functions, and/or types, will be detectable at compile time.  Semantic
extensions (e.g., thread-safety) will require explicit compile-time
detection facilities, if those are desired.

Also, note that while all language bindings of the GSS-API will have
runtime environments, not all will have compile-time environments, so
talk of compile-time feature detection is language-specific, so I may
insist that all such facilities be specified per-language binding.

> significant value from an IANA registry?

Hmmm, something to think about.  Are there any disadvantages in having a
registry for each of the relevant namespaces?

> I do believe we want an IANA registry for error values and possibly

Small GSS namespaces should definitely have an IANA registry, yes.

>    smaller documents appropriate?

Excellent question.  So far we have multiple documents defining
different little bits of it, so I figured we should at the very least
have a single document to serve as a guide -- that's the document that
you comment on.

We could, for now, continue with small docs and later merge them.  I do
find it easier working that way, but if the [putative] WG disagrees then
I can adjust.  Reguargless, a guide might be useful even if all the
other docs are merged into one, either as a temporary guide to KITTEN's
work, or as an informational RFC to guide readers of KITTEN's work.

>    backward-compatible parts of V3?

How would we so encourage them?

> 3) What parts of what we propose are actually backward incompatible?

None, I don't think, but some can cause portability problems, which
Martin pointedly brought up, and which I tried to address in the guide
doc.

The canonical example of that so far is thread-safety: an application
that assumes that the GSS-API is thread-safe wouldn't be portable[*].

[*]  Well, by the nature of Java one would expect the Java bindings of
     the GSS-API to be thread-safe, implicitly if not explicitly; we can
     make sure that future language bindings are clear on this, as I'm
     sure the C# bindings will be.

Note that I threw in fork-safety as well :/

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 13:52:47 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    >> 2) To what extent do we want to encourage V2 implementations to
    >> adopt backward-compatible parts of V3?

    Nicolas> How would we so encourage them?

I meant more do we think this is desirable or confusing?

    >> 3) What parts of what we propose are actually backward

    Nicolas> None, I don't think, but some can cause portability
    Nicolas> problems, which Martin pointedly brought up, and which I

I think that supporting mechs that do not have a good thing to return
for gss_export_name may be such a feature.  That's only one part of
one of the three options my naming draft now discusses though; it is
not clear the working group will adopt it.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 Oct 2004 13:03:06 -0500

> I meant more do we think this is desirable or confusing?

I don't get this.

> not clear the working group will adopt it.

I'm becoming unconvinced by the "some mechanisms have no canonical
names" argument.  Considering x.509 certs with multiple subjectAltName's
I think that SPKM-like mechanisms could pick one as a canonical name
either based on the query name and name type given to GSS_Import_name()
and some rules, either site-specific or standardized.

Thinking of IPsec I realize that any mechanisms like SPKM would have to
involve assertion of one of the several names associated with the
credentials used.  So, the lack of a canonical name due to a
multiplicity of names associated with credentials need not mean anything
more than that users/apps should be careful which name they use.

IOW, I think we'll always be able to have MNs; MNs are trivially
exportable, as long as the mechanisms' designers can agree on an
exportable representation of their MNs, but given the above I don't see
why they wouldn't.

Of course, the extensions for MN->machine-UID/GID mapping remain highly
desirable.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 14:53:16 -0400

To be useful you need to standardize which name you pick as the
canonical name from a cert.

Also, the compatibility issue is not just about whether you have
something to return.  The issue also includes the question of whether
a gssapi v2 application that uses gss_export_name as intended by the
v2 spec will get the desired behavior.

If you pick some arbitrary mapping then you may have an implementable
protocol but you will not have a protocol that meets users' needs.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 Oct 2004 14:00:36 -0500

> canonical name from a cert.

For a given query form.

Remember, GSS_Import_name() w/o a name type OID means that the name is
in a mechanism-specific form, so such a mechanism could still let the
app have full control over which name to user [i.e., assert].

Also, such a mechanism could add new generic name types and syntaxes as
well.

> v2 spec will get the desired behavior.

It will, as long as the peer asserts the same name next time.

> protocol but you will not have a protocol that meets users' needs.

A single arbitrary mapping is not the only way.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 15:11:38 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Mon, Oct 25, 2004 at 02:53:16PM -0400, Sam Hartman
    >> canonical name from a cert.

    Nicolas> For a given query form.

It's not at all that simple.  Considre a mechanism that sends an X.509
cert over the wire.  Such a mechanism needs to either carry additional
data (which name should be exported) or it needs to have a single
mapping for the mechanism.

Also keep in mind that we want GSSAPI applications to use default
credentials when possible.  That means that for a V2 application,
there needs to be something reasonable that happens when
gss_export_name is called on the name of default credentials and on
the name of a context established with those credentials.

This all strongly points in the direction of an expectation of a
single name form exported by gss_export_name for v2 mechanisms.

I'm also not really
comfortable with the term query form as a description of the input to
gss_import_name.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 Oct 2004 14:14:09 -0500

> mapping for the mechanism.

I said as much.  And I endorse the notion of asserting an ID in the
context token.

> the name of a context established with those credentials.

Sure, but this need not require standardizing a canonical name selection
method.  A mechanism could have its users select a name at logon time,
for example.

> single name form exported by gss_export_name for v2 mechanisms.

Only when starting from GSS_C_NO_NAME, but see above.

> comfortable with the term query form as a description of the input to

Alternatives?

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 15:20:49 -0400

>> I'm also not really comfortable with the term query form as a
    >> description of the input to gss_import_name.

    Nicolas> Alternatives?

imported name?
Name type?

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 Oct 2004 14:28:26 -0500

>     >> description of the input to gss_import_name.

Isn't an exported name, re-imported "imported?"

A name that's been canonicalized or that is output by
GSS_Accept/Inquire_sec_context() is an MN, whereas a name imported by
GSS_Import_name() with a name type other than exported name is not.
What do we call a name that is not an MN?

I like "query name."  I've never really liked "MN."

> Name type?

Huh?

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 Oct 2004 14:45:18 -0500

Also, for default name, think of the MIT krb5 ccache.  It can store
tickets for more than one client principal, but the ccache file format
specifies a default principal name so that even if one does store
tickets for multiple different client principals it is always clear
which to use when not explicitly requesting one or another name.

Similarly with x.509 certs.  Not only might one have certs with multiple
names, one might also have multiple certs, either for different names or
for the same names but with various other differences (e.g., CA chain;
why would ould one do so?  I dunno, but one could).  As a result,
whatever facility one uses to store/manage certs and their private keys
one might also want to select one cert and name to act as a default
credential.

If one thinks of a ccache as a credential, rather than a TGT as a
credential, then certs look less special w.r.t. having multiple names.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Oct 2004 16:36:25 -0400

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> Also, for default name, think of the MIT krb5 ccache.  It
    Nicolas> can store tickets for more than one client principal, but
    Nicolas> the ccache file format specifies a default principal name
    Nicolas> so that even if one does store tickets for multiple
    Nicolas> different client principals it is always clear which to
    Nicolas> use when not explicitly requesting one or another name.

Remember the thread on krbdev where we proposed to drop that and use
the best match principal for the service in question.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 25 Oct 2004 15:42:52 -0500

> the best match principal for the service in question.

That does not change the fact that one could (and one implementor has)
treated Kerberos credentials in that way.  This helps me view the
Kerberos V mechanism as not so different from x.509 certificate-based
mechanisms w.r.t. to credentials having multiple names associated with
them.

Nico
--