Subject: [abfab] Review on gss-eap-03

From: "Jim Schaad" <[email-masked]>
Date: Fri, 28 Oct 2011 14:35:21 -0700

Here are some quick comments on the -03 draft.

Jim

In section 1.2 - should disucss reliablity requriements in the event that
you are an EAP passthrough authenticator in last paragraph

Is the ABNF for "name" still wrong?

section 3.4 missing

Section 4 - does/should the application get any control ovret the set of
allowable EAP methods to be used or is that purely a fucntion of your
GSS-API library

For consistency the paragraph:
Tokens from the initiator to acceptor use an outer token type of 06
   01; tokens from acceptor to initiator use an outer token type of 06
   02.  These token types are registered in the registry of RFC 4121
   token types; see Section 8.1.

should refer to the "token ID" rather than the "outer token type"  either
that or the item in the table should be updated.

section 5.2 refers to "token type" - I think that maybe this is the most
constant phrase to be used.

I will say that this version did harmonize and make the token naming scheme
much more consistent and readable.  I think this is a big improvement.

s/secondsubtoken/second subtoken/ (in the table)

Section 5.3 -
        Is there going to be a rule that you should send two error subtokens
in the even t\the length is greater than 8?  I can understand saying you
should ignore the extended bytes but should you really ignore the error code
itself?

Section 5.4 - you have different names for the acceptor name subtokens in
the description of what is permitted and the actual subtoken names - I think
you might want to harmonize this.

Is there a rason that the EAP request subtoken is not documented in section
5.4 since it is a required subtoken from in the Initial State message from
the acceptor?

Section 5.4.1 - I realize this is a debugging string (Vender Subtoken) but
is there any reason in this day and age not make it a UTF8 string?  (Other
than it is not one for Kerbros)

Section 5.4.3 - Should something be said about what the acceptor should do
if the initiator sends an acceptor name which is not completely correct for
the specific acceptor.  I am thinking specifically of things like adding a
host name or adding some service specifics to the acceptor name.  Is this
permitted?  Or is this and error condition or since this is typically not
sent is the acceptor name from the client to be used in all events. (unless
totally wrong)

para #2 s/this token/This token/

Section 5.5 s/ACCEPTOR/acceptor/

The first bullet of this section is causing me some mental problems.  The
acceptor cannot confirm that the protected result and the final result are
consistent - this is hidden from the acceptor.  --- or you need to be
passing the protected result as a RADIUS attribute, at which point it is not
really protected anymore.

The acceptor can confirm that a key has been delivered to it, but it does
not know the source of the key - i.e. was it derived or just transmitted
inside of the EAP session.

Should the acceptor or the initiator send the error subtoken - or should the
acceptor be looking for clear EAP messages and generate a failure?

I think you need to carefully re-read the section and verify that you think
it is correct.

Setion 5.6 - Please tell me which type of channel binding I am getting at
this point. (I know it is GSS-API channel binding, but given that two
different types are discussed in the document I think being explcit would be
good.)

Section 6 -  Is the KMSK in the "Tn = " line supposed to be GMSK?

Section 6.1 - I am unclear what the extension option field is referring to
please clarify.

---

From: Luke Howard <[email-masked]>
Date: Sat, 29 Oct 2011 09:17:45 +1100

> allowable EAP methods to be used or is that purely a fucntion of your

That's a good question. The application can select which GSS EAP variants (i.e. encryption type) using GSS_Set_neg_mechs (RFC 4178). But I'm not sure how the application might select EAP methods. Sounds like something we could make a settable attribute on either the credential or context object.

> should ignore the extended bytes but should you really ignore the error code

This doesn't sound right, there should be a single error token, extra bytes are ignored for extensibility.

> than it is not one for Kerbros)

Makes sense.

> sent is the acceptor name from the client to be used in all events. (unless

Also, given the entire exchange is not protected, what are the security implications given the acceptor name is vulnerable to a MITM? Should we send a MIC of it in the last token?

> different types are discussed in the document I think being explcit would be

Being explicit in every instance would be useful, I agree, because it is very confusing when you first start to understand this protocol.

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Fri, 28 Oct 2011 18:02:04 -0500

> That's a good question. The application can select which GSS EAP variants (i.e. encryption type) using GSS_Set_neg_mechs (RFC 4178). But I'm not sure how the application might select EAP methods. S…

Oh, two-level negotiation.  I've wondered before about this.  We in
the SASL/GSS community have grown to dislike two-level negotiations
very much.  The primary issue relates to cryptographic strength.  I
expect GSS-EAP to not imply a two-level negotiation for per-msg token
enctypes.  But a two-level negotiation for authentication would not
exactly be great.

IHow about an option of OID per EAP method, and an OID for the variant
that will negotiate any EAP method?

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Sat, 29 Oct 2011 10:05:30 +1100

> How about an option of OID per EAP method, and an OID for the variant

So NxM OIDs, where N is the |enctypes| and M |EAP mechanisms|? Sounds a bit ugly...

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Fri, 28 Oct 2011 18:08:26 -0500

> So NxM OIDs, where N is the |enctypes| and M |EAP mechanisms|? Sounds a bit ugly...

N = 1 for now.

But, yeah.  I don't really mind this.

---

From: Luke Howard <[email-masked]>
Date: Sat, 29 Oct 2011 10:10:42 +1100

>> So NxM OIDs, where N is the |enctypes| and M |EAP mechanisms|? Sounds a bit ugly...

2: AES-128 and AES-256.

> But, yeah.  I don't really mind this.

I suppose if it's done dynamically, it's not so bad...

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Fri, 28 Oct 2011 18:30:31 -0500

> I suppose if it's done dynamically, it's not so bad...

Using mech attrs APIs it can be pretty easy, methinks!

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 28 Oct 2011 18:18:36 -0700

> -----Original Message-----
> From: Nico Williams [mailto:[email-masked]]
> Sent: Friday, October 28, 2011 4:02 PM
> To: Luke Howard
> Cc: Jim Schaad; [email-masked]; [email-masked]
> Subject: Re: [abfab] Review on gss-eap-03
> 
> >> Section 4 - does/should the application get any control ovret the set
> >> of allowable EAP methods to be used or is that purely a fucntion of
> >> your GSS-API library
> >
> > That's a good question. The application can select which GSS EAP variants
> (i.e. encryption type) using GSS_Set_neg_mechs (RFC 4178). But I'm not sure
> how the application might select EAP methods. Sounds like something we
> could make a settable attribute on either the credential or context object.
> 
> Oh, two-level negotiation.  I've wondered before about this.  We in the
> SASL/GSS community have grown to dislike two-level negotiations very
> much.  The primary issue relates to cryptographic strength.  I expect GSS-EAP
> to not imply a two-level negotiation for per-msg token enctypes.  But a two-
> level negotiation for authentication would not exactly be great.

I don't think that is an issue for this.  I would assume that the EAP method is going to be required to generate enough bytes for the selected GSS-API key derivation function.

> 
> IHow about an option of OID per EAP method, and an OID for the variant that
> will negotiate any EAP method?
> 
> Nico
> --

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 28 Oct 2011 18:20:44 -0700

> From: Luke Howard [mailto:[email-masked]]
> Sent: Friday, October 28, 2011 4:06 PM
> To: Nico Williams

I think it might get even uglier which is why I hesitated to mention it.
You might say that you require to use of the new EAP-TLS-Tunnel method (and
might want to say something about the cert domain although that is probably
derived from the credential) and then want to specify that a machine and
user EAP method need to be run inside of the tunnel.  This starts making the
array huge.

Jim

> -- Luke=

---

From: Sam Hartman <[email-masked]>
Date: Sat, 29 Oct 2011 11:08:22 -0400

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

    Nico> On Fri, Oct 28, 2011 at 5:17 PM, Luke Howard <[email-masked]> wrote:
    >>> Section 4 - does/should the application get any control ovret
    >>> the set of allowable EAP methods to be used or is that purely a
    >>> fucntion of your GSS-API library
    >> 
    >> That's a good question. The application can select which GSS EAP
    >> variants (i.e. encryption type) using GSS_Set_neg_mechs (RFC
    >> 4178). But I'm not sure how the application might select EAP
    >> methods. Sounds like something we could make a settable attribute
    >> on either the credential or context object.

    Nico> Oh, two-level negotiation.  I've wondered before about this.
    Nico> We in the SASL/GSS community have grown to dislike two-level
    Nico> negotiations very much.  The primary issue relates to
    Nico> cryptographic strength.  I expect GSS-EAP to not imply a
    Nico> two-level negotiation for per-msg token enctypes.  But a
    Nico> two-level negotiation for authentication would not exactly be
    Nico> great.
Please see the discussion in section 4.
I thought we already had consensus on this approach even though it was a
    Nico> two-level approach.
If we do I am not in favor of opening it again.

    Nico> IHow about an option of OID per EAP method, and an OID for the
    Nico> variant that will negotiate any EAP method?

The main problem with this is that the acceptor does not choose or
influence the EAP method.  The EAP method is a factor of what identity
is chosen.  IT's like proposing an OID for kerberos plus a particular
preauth type.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Sun, 30 Oct 2011 19:20:18 -0400

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

    Jim> Is the ABNF for "name" still wrong?

I don't think so.
What problem or oddity do you see?
Hmm.
I see that realm is only permitted if host is present. I think I've
fixed that.
I think it's correct now in 04.

    Jim> section 3.4 missing

    Jim> Section 4 - does/should the application get any control ovret
    Jim> the set of allowable EAP methods to be used or is that purely a
    Jim> fucntion of your GSS-API library

Currently no mechanism is provided for an application to enfluence this.
A mechanism probably should have system-level policy configuration.
A mechanism could expose a credential option on the initiator.
If we ever need to standardize a credential option we can, but I don't
see a need for that now.

    Jim> For consistency the paragraph: Tokens from the initiator to
    Jim> acceptor use an outer token type of 06 01; tokens from acceptor
    Jim> to initiator use an outer token type of 06 02.  These token
    Jim> types are registered in the registry of RFC 4121 token types;
    Jim> see Section 8.1.

My understanding is that the ID describes which type of token (token
type) we are dealing with.
So, I've phrased it as token s with from acceptor to initiator use  an
inner token type with ID xxx.
1) token type with ID 
and 2) inner not outer

    Jim> should refer to the "token ID" rather than the "outer token
    Jim> type" either that or the item in the table should be updated.

    Jim> section 5.2 refers to "token type" - I think that maybe this is
    Jim> the most constant phrase to be used.

I've updated the registry to talk about token type identifiers.

    Jim> I will say that this version did harmonize and make the token
    Jim> naming scheme much more consistent and readable.  I think this
    Jim> is a big improvement.
Great!

    Jim> s/secondsubtoken/second subtoken/ (in the table)

    Jim> Section 5.3 - Is there going to be a rule that you should send
    Jim> two error subtokens in the even t\the length is greater than 8?
    Jim> I can understand saying you should ignore the extended bytes
    Jim> but should you really ignore the error code itself?

In 04 we have initiators MUST ignore octets beyond the GSS EAP error
code for future extensibility.  Thanks for the catch.

    Jim> Section 5.4 - you have different names for the acceptor name
    Jim> subtokens in the description of what is permitted and the
    Jim> actual subtoken names - I think you might want to harmonize
    Jim> this.

    Jim> Is there a rason that the EAP request subtoken is not
    Jim> documented in section 5.4 since it is a required subtoken from
    Jim> in the Initial State message from the acceptor?

I've added a reference. However I think it's better to document EAP
request and response near each other.
Note that if we adopt the proposal to reduce a round trip this subtoken
goes away from initial state.

    Jim> Section 5.4.1 - I realize this is a debugging string (Vender
    Jim> Subtoken) but is there any reason in this day and age not make
    Jim> it a UTF8 string?  (Other than it is not one for Kerbros)

It doesn't exist for Kerberos (which has no vendor string I'm aware of)
so I don't think that's a concern.

I've made it UTF-8; I don't care.

    Jim> Section 5.4.3 - Should something be said about what the
    Jim> acceptor should do if the initiator sends an acceptor name
    Jim> which is not completely correct for the specific acceptor.  I
    Jim> am thinking specifically of things like adding a host name or
    Jim> adding some service specifics to the acceptor name.  Is this
    Jim> permitted?  Or is this and error condition or since this is
    Jim> typically not sent is the acceptor name from the client to be
    Jim> used in all events. (unless totally wrong)

I think you mean 5.4.2 not 5.4.3?
My assumption is that you need to send a superset of what the acceptor
 expects, else things will fail at channel binding. I think you want to
 leave it to channel binding to fail unless an IDP wants to implement
 some form of aliasing.

    Jim> para #2 s/this token/This token/

    Jim> Section 5.5 s/ACCEPTOR/acceptor/

    Jim> The first bullet of this section is causing me some mental
    Jim> problems.  The acceptor cannot confirm that the protected
    Jim> result and the final result are consistent - this is hidden
    Jim> from the acceptor.  --- or you need to be passing the protected
    Jim> result as a RADIUS attribute, at which point it is not really
    Jim> protected anymore.

For combined authenticators the acceptor can and should evaluate the
protected result.
For pass-through authenticators the acceptor should confirm there's AAA
success if there is EAP success.

    Jim> The acceptor can confirm that a key has been delivered to it,
    Jim> but it does not know the source of the key - i.e. was it
    Jim> derived or just transmitted inside of the EAP session.

Here, we mean the security claim discussed in section 7.10 of RFC 3748, 
which probably includes transmitting a key.
Their term, not mine.
I've added a reference.

    Jim> Should the acceptor or the initiator send the error subtoken -
    Jim> or should the acceptor be looking for clear EAP messages and
    Jim> generate a failure?

I don't understand.

    Jim> I think you need to carefully re-read the section and verify
    Jim> that you think it is correct.

I think it is consistent with what EAP does and what our implementation
does.
There are some disadvantages to how EAP handles failures.
We can discuss at IETF 82 if you like.

    Jim> Setion 5.6 - Please tell me which type of channel binding I am
    Jim> getting at this point. (I know it is GSS-API channel binding,
    Jim> but given that two different types are discussed in the
    Jim> document I think being explcit would be good.)

Also added a forward reference.

    Jim> Section 6 - Is the KMSK in the "Tn = " line supposed to be
    Jim> GMSK?
Yes.

    Jim> Section 6.1 - I am unclear what the extension option field is
    Jim> referring to please clarify.

This was all wrong and has been fixed. Thanks for the reality check.

---

From: Nico Williams <[email-masked]>
Date: Sun, 30 Oct 2011 18:34:07 -0500

> If we ever need to standardize a credential option we can, but I don't

I think Luke suggested using the SPNEGO gss_get/set_neg_mechs()
functions for this.  I.e., you could treat GSS-EAP as a
mechanism-negotiation mechanism, sort of.  Of course, the way these
functions work we'll need something better in the case of SPNEGO being
used to negotiate GSS-EAP.  We really need a notion of credentials
acquired with credentials, so that we can first acquire a credential
handle for GSS-EAP, set what methods it will negotiate, then pass
*that* credential handle to another function for acquiring a larger
credential set.  In other words, we need a new credential set model
for GSS, and the best thing to do for now is to punt.

I don't see configuration as being satisfactory for this in the long-term.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Mon, 31 Oct 2011 10:38:09 +1100

> functions for this.  I.e., you could treat GSS-EAP as a

I wasn't actually suggesting this, I just noted you could use it to select which GSS EAP enctypes to select, but not the underlying EAP method.

Using gss_set_cred_option() would work today (even on an SPNEGO credential, because non-EAP GSS mechanisms will ignore the call).

> for GSS, and the best thing to do for now is to punt.

Could you use gss_add_cred() for this?

Myself, I find gss_acquire_cred() + gss_set_cred_option(EAP_METHODS) easier to understand, particularly if this kind of application-level configurability is an edge case (I really want applications not to have to worry about this; rather, they use SPNEGO, and the mechanism and/or its credential manager sorts things out for you).

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Sun, 30 Oct 2011 19:22:32 -0500

> Could you use gss_add_cred() for this?

Sadly, no.  You'd think, by its name, but it would need *two* input
credential handles to do what we need it to.

I.e., we need a GSS_Add_cred_to_cred_set() that takes one credential
handle that is to be an element of the other.  We'd then need not
GSS_Set_neg_mechs() but GSS_Set_net_creds().

I.e., we want credential handles as sets of credential handles, with
credentials for mechanism-negotiation mechanisms themselves acting as
sets (nested sets).

> Myself, I find gss_acquire_cred() + gss_set_cred_option(EAP_METHODS) easier to understand, particularly if this kind of application-level configurability is an edge case (I really want applications…

GSS_Add_cred() was a mistake :(

We may need a wrapper around all this to make GSS dead simple for most apps.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Sun, 30 Oct 2011 20:42:05 -0400

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

    Nico> On Sun, Oct 30, 2011 at 6:20 PM, Sam Hartman
    Nico> <[email-masked]> wrote:
    >>    Jim> Section 4 - does/should the application get
    >> any control ovret    Jim> the set of allowable EAP
    >> methods to be used or is that purely a    Jim>
    >> Currently no mechanism is provided for an application to
    >> enfluence this.  A mechanism probably should have system-level
    >> policy configuration.  A mechanism could expose a credential
    >> option on the initiator.  If we ever need to standardize a
    >> credential option we can, but I don't see a need for that now.

    Nico> I think Luke suggested using the SPNEGO
    Nico> gss_get/set_neg_mechs() functions for this.  I.e., you could
    Nico> treat GSS-EAP as a mechanism-negotiation mechanism, sort of.

Luke suggested that you could include the EAP type in the OID.
I explained that's all sorts of wrong and pointed you to the existing
text discussing multi-layer negotiation.
To recap, EAP method is much more like kerberos preauth mechanism: a
matter that depends on the identity.
The acceptor doesn't really know what  method is being used.
I mean it knows the outer method, but that will probably be something
like TTLS.
The acceptor is not in a position to construct the set of OIDs offered
if the EAP method is included, because the set of EAP methods supported
depends on the initiator identity.
We've discussed this issue going back as far as my initial feasibility
analysis. I realize that was not a consensus document, but I think it's
fair  to ask you to go back and read that document's discussion of this
issue and the current text before jumping into the discussion.
    Nico> I don't see configuration as being satisfactory for this in
    Nico> the long-term.

I do, because it's a property of the identity.  I think acceptors will
sometimes want to know information about LOA of authentication and will
sometimes deny authorization based on that.  However, in most cases, an
initiator application has no business mandating an EAP method, and in
most cases an acceptor couldn't even if it wanted to.

--Sam

---

From: Luke Howard <[email-masked]>
Date: Mon, 31 Oct 2011 11:53:10 +1100

> Luke suggested that you could include the EAP type in the OID.

FTR Nico suggested this.

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Sun, 30 Oct 2011 20:40:37 -0500

To be fair krb5 pre-auth was never an issue before because a) we
didn't have initial credential acquisition interfaces for GSS, b) we
didn't have IAKERB.  It's likely that this will never be a real issue.
 Indeed, what I'd want to do as a client app is specify things like
"don't use weak authentication methods" and enctypes/cipher suites.  I
don't think I'd care to choose "PKINIT with user certs on a smartcard"
vs. "PKINIT with SACRED instead of smartcards" vs. FAST armored
PA-ENC-TIMESTAMP.  So, I give, thanks for the analogy.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 31 Oct 2011 00:39:01 -0500

> PA-ENC-TIMESTAMP.  So, I give, thanks for the analogy.

This is what had me nervous Sam, and I now agree that I shouldn't look
at GSS-EAP through the same prism when it comes to two-level
negotiation.

What I want is probably best left as cred options (and possibly a
req_flag, but I want to avoid adding req_flags whenever we can, since
that's a very limited namespace) for expressing the app policies I
mentioned above.  Cred options on the default credential can be had by
acquiring a credential for desired_name = GSS_C_NO_NAME and setting
cred options on that, which is how we'd avoid having to add req_flags.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 31 Oct 2011 09:09:55 -0400

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

    Nico> This is what had me nervous Sam, and I now agree that I
    Nico> shouldn't look at GSS-EAP through the same prism when it comes
    Nico> to two-level negotiation.

    Nico> What I want is probably best left as cred options (and
    Nico> possibly a req_flag, but I want to avoid adding req_flags
    Nico> whenever we can, since that's a very limited namespace) for
    Nico> expressing the app policies I mentioned above.  Cred options
    Nico> on the default credential can be had by acquiring a credential
    Nico> for desired_name = GSS_C_NO_NAME and setting cred options on
    Nico> that, which is how we'd avoid having to add req_flags.

I agree cred options are a fine way to get this sort of app policy.  I
think we need not specify them now; they can be in a separate spec.

I'm personally dubious whether we'll need to standardize them. For me,
it would be worthwhile if someone were going to implement and someone
else indicated a desire to use the option in an application that was not
closely associated with the implementation.
If that happens I'm all for standardizing. If that doesn't happen and
there's a consensus to standardize anyway, I'm not against.

--Sam

---

From: Nico Williams <[email-masked]>
Date: Mon, 31 Oct 2011 09:57:48 -0500

The obvious application for these policy options is Luke's pam_gss.

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 31 Oct 2011 18:11:46 -0700

> From: Sam Hartman [mailto:[email-masked]]
> Sent: Sunday, October 30, 2011 4:20 PM
> To: Jim Schaad
> Cc: [email-masked]; [email-masked]
> I see that realm is only permitted if host is present. I think I've fixed
that.
> I think it's correct now in 04.

That was the specific error that I saw.

> If we ever need to standardize a credential option we can, but I don't see
a
> need for that now.
inner
> token type with ID xxx.

Looks fine

> In 04 we have initiators MUST ignore octets beyond the GSS EAP error code
> for future extensibility.  Thanks for the catch.
> 
request
> and response near each other.
goes
> away from initial state.
> It doesn't exist for Kerberos (which has no vendor string I'm aware of) so
I
> don't think that's a concern.
> 
leave it to
> channel binding to fail unless an IDP wants to implement  some form of
> aliasing.

In 5.4.2 s/hosntame/hostname/

I meant 5.4.3 - because I was assuming this was an Acceptor error rather
than an Initiator.  That is if the Acceptor name is not a superset then it
would return an error.  The question is should you both error and return the
response in some sense.  

One possibility is that the Initiator sends name #1, the Acceptor replies
with name #2 and then the intiator says that this is acceptable and sends
name #2 as part of the channel binding.    In this case the was no error but
the initator name is not a superset of the acceptor name that came back.

>     Jim> Section 5.5 s/ACCEPTOR/acceptor/

Not fixed

> success if there is EAP success.

Ok - I think this is more clear now.

> Here, we mean the security claim discussed in section 7.10 of RFC 3748,
which
> probably includes transmitting a key.
> Their term, not mine.
> I've added a reference.
> 
Ok

> We can discuss at IETF 82 if you like.

I think this would probably be a good idea - just so I can be sure that we
understand each other and what the doc says.