Subject: [abfab] Trying to build the first GSS-API token ---- draft-ietf-abfab-gss-eap-02

From: "Jim Schaad" <[email-masked]>
Date: Sat, 8 Oct 2011 18:44:48 -0700

Sam,

I am trying to construct the first token to be returned from the call to
GSS_Init_sec_context and I am having a couple of problems.

1.  I don't know the value of the OID as it is not in the document (minor I
can always fudge this value)

2.  Next item in the field is a token ID (note that this is capitalized as
iD in the current draft which is probably a typo).  This should contain
either the value of <06 01> according to section 5 of this document.
However it would be <00 01> if it was using the tokens defined in RFC 4121.
It is not clear to me if you are re-using the same values from section 4.1
in that document or defining new values in which case this needs to be
reflected in section 8.1 of this document.

3. Next item in the field is an inner token type - this is a 32-bit number
-- oh wait, I just figured this out.   It would be clearer if you used the
following terms:
	First subtoken type
	First subtoken length
	First subtoken body
	Second subtoken type.

I would be happy if you were consistent on the use of either inner token or
subtoken but mixing them got me confused.

Jim

---

From: Luke Howard <[email-masked]>
Date: Sun, 9 Oct 2011 12:11:51 +1100

Jim,

RFC 4121 tokens are for message protection services only. (at least fast reauth notwithstanding)

OID awaits assignment, we use one in PADL's arc now.

Luke

Sent from my iPhone

On 09/10/2011, at 12:44, "Jim Schaad" <[email-masked]> wrote:

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

---

From: Sam Hartman <[email-masked]>
Date: Sun, 09 Oct 2011 11:05:58 -0400

I will attempt to standardize on subtoken.
I definitely agree we need more clarity around the RFC 4121 token type
registry.
We use a different token type for our context tokens from Kerberos
because they have nothing in common.

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 9 Oct 2011 14:57:09 -0700

I am confused in a way.  I would have thought that all of the token types
are defined on a per mechanism method, thus re-using the same value would
have no theoretical problems.  I recognize that they could present an issue
if you use a single code base for implementing multiple mechanisms and use a
single switch statement to deal with the token types.  

I guess my question would be why would we want to look at the 4121 token
type registry for anything given that it should be mechanism specific?

Jim

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Sunday, October 09, 2011 8:06 AM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: Re: Trying to build the first GSS-API token ----
draft-ietf-abfab-gss-
> eap-02
> We use a different token type for our context tokens from Kerberos because
> they have nothing in common.

---

From: Sam Hartman <[email-masked]>
Date: Sun, 09 Oct 2011 18:01:56 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> I guess my question would be why would we want to look at the
    Jim> 4121 token type registry for anything given that it should be
    Jim> mechanism specific?

Well, the context level tokens are probably per-mechanism at least for
the most part.  However, per-message tokens are going to be common
across all the 4121-like mechanisms (EAP, Kerberos, SCRAM, SAML ECP).
If there is some option added--say a DH exchange for PFS--there's a fair
chance it will apply to multiple mechanisms.  If it does, it would be
nice to reuse code points.

If we're doing things like Kerberos fastreauth for EAP, then it becomes
even more possible to have overlaps.  So, my rationale is that there's
no harm in using different token IDs for the different context tokens
and there's at least some chance of potential value in doing so.  If you
would rather do something else to avoid confusion, etc, we can do that.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Oct 2011 10:50:03 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:
    Jim> 3. Next item in the field is an inner token type - this is a
    Jim> 32-bit number -- oh wait, I just figured this out.  It would be
    Jim> clearer if you used the following terms: First subtoken type
    Jim> First subtoken length First subtoken body Second subtoken type.

    Jim> I would be happy if you were consistent on the use of either
    Jim> inner token or subtoken but mixing them got me confused.

OK, I'm trying to be consistent with the following.  An inner token is a
non-ASN.1 structure carried in the any in the GSSAPI-Token production
defined in RFC 2743. I.E. the context token without the application tag
and OID wrapper.

GSS-EAP inner tokens contain a token ID and a series of subtokens.
Subtokens have types, lengths and values.  I believe I've made changes
to the document to be consistent with this terminology.

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Oct 2011 10:10:52 -0500

> defined in RFC 2743. I.E. the context token without the application tag

Well, it could be ASN.1, but the point is it's not defined by RFC2743
-- it's defined by the mechanism.

> to the document to be consistent with this terminology.

Given that the context token exchange is synchronous, there's no need
for any token IDs as such.  Or so I would think (sub-token IDs, sure,
if there's any sub-tokens that require identification).

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Oct 2011 11:31:18 -0400

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

    Nico> Given that the context token exchange is synchronous, there's
    Nico> no need for any token IDs as such.  Or so I would think
    Nico> (sub-token IDs, sure, if there's any sub-tokens that require
    Nico> identification).

    Nico> Nico --

Sure, although RFC 1964 and RFC 4121 had them.  And we're talking about
two bytes.

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Oct 2011 11:11:23 -0500

> Sure, although RFC 1964 and RFC 4121 had them.  And we're talking about

IMO it was a mistake in RFC1964.  We shouldn't repeat mistakes.  As
far as mistakes go, it's not a big deal, so I don't really care.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 18 Oct 2011 16:57:18 -0700

That looks like it should remove my confusion.

Jim

> Sent: Tuesday, October 18, 2011 7:50 AM
> To: Jim Schaad
> Cc: [email-masked]
draft-ietf-abfab-gss-
> defined in RFC 2743. I.E. the context token without the application tag
and
> OID wrapper.
> Subtokens have types, lengths and values.  I believe I've made changes to
> the document to be consistent with this terminology.