Subject: [abfab] Review of draft-ietf-abfab-gss-eap-02

From: "Jim Schaad" <[email-masked]>
Date: Tue, 4 Oct 2011 13:34:44 -0700

Sam and Josh,

I apologize; I have been going through unsent mail and other files where I
make comments.  I had actually done most of a review, but had not completed
it and therefore had not sent the review to the list.  I thought it was out
but was in error, thus my earlier message.

Jim

1.  In section 1.2, under what circumstances would an acceptor fail to
respond to an initiator short of a transport failure?  Can this ever happen
in a success  case?  If it cannot then I would suggest that /acceptor may
respond/ be changed to /acceptor responds/      I guess there would also be
a question of the initial negotiation being anything other than
query/response - for example an EAP retry would be sourced from the acceptor
and might not be expected by the initiator.

2.  In section 1.2 para #2 - we have not established what the peer and
authenticator are for EAP.  It would be a good idea to identify who is whom.
Suggest adding a sentence similar to the first sentence in the previous
paragraph.

3. In section 1.2 - I have always been worried about the statement that EAP
authentication can start w/ the peer, but the first message is always from
the authenticator.  I believe that it would be more correct to state that
EAP authentication always starts with the authenticator, but it may start
with the peer for any given EAP mechanism.

4.  In section 1.2 - I would suggest that /GSS-API peer/ becomes /GSS-API
acceptor/  This keeps the term peer to be used only for EAP and only for the
GSS-API initiator (possibly unless we are dealing with terms for an EAP
pass-through system)

5.  In section 1.2 - You say that the GSS-API acceptor acts as an EAP
pass-through authenticator.   I am not sure if that means that the GSS-API
acceptor needs to deal with the requirements for an EAP pass-through such as
the fact that it is supposed to check the record value of EAP item rather
than just pass-it through.

6. In section 3 - I have a real problem with the first sentence in the
section.  I don't believe that it is a true statement.  What is
authenticated is going to be based on what the EAP method is and what is
expected.  I have always assumed that it starts by authenticating a user to
a realm as the single authentication and different things for mutual
authentication.  It might be that the sentence was supposed to be "EAP
authenticates within a realm."

7. Is the BNF in section 3.1 supposed to ensure that  a name cannot be
"[email-masked]"?  Currently you would need to say "shartman/@janet.edu"

8.  In section 3.1 An example of a GSS_C_NT_HOSTBASED_SERVICE name would be
useful for people w/o sufficient background.  I would need to look farther
on this, but based on this text I would end up with something like
"smtp.example.com@SMTP" as a host name.  However this looks very strange to
me.

9.  In section 3.3 -- Which acceptor name must be sent in the AAA transport?
There are three different ones listed above, or this could be a completely
different field.  It might also be that the portions are to be re-composed
in order to send onto the client in the EAP channel, if this is the case
then why do the decomposition?

10.  In section 3.3 - is the client signaling mutual authentication on the
EAP channel or on the GSS-API channel?

11. In section 5.5 - who does the initiator return the error message to?
What state should it transition to?  Should it still accept an error from
the acceptor in the GSS-API protocol?

12.  In section 5.6 - It is not clear to me if one can progress from the
Extension State to the Extension state rather than the completed state as
part of negotiation of option features.  Is this something that needs to be
clarified?

13.  In Section 5.6.1 - is the flag bit of 0x1 reserved for some purpose?
If so this needs to be documented.  If not then why not start with mutual
auth at 0x1 rather than 0x2.

14.  In section 5.6.3 - Do I assume that it is so obvious that it does not
need to be stated that the EAP negotiated key is used for the MIC w/o any
further key derivation work?

15. In section 5.7 - I am not clear what set of channel binding data needs
to be included in the EAP method.  Would this be data about the channel
carrying the GSS-API methods or the GSS-API/AAA channel or both?  I assume
this should really include channel data all the way from the acceptor to the
EAP server but I don't know that.  How much does this differ from the
acceptor name referenced in question 9?

Typos:

s/thearchitecture/the architectural/  or /the architectures/
s/authorisation/authorization/    - American English spellings preferred
check if passthrough is a single word or should be pass-through.  My
dictionary dislikes it as a single word.
s/receievs/receives/
s/faris/far is/

---

From: Klaas Wierenga <[email-masked]>
Date: Wed, 5 Oct 2011 09:47:35 +0200

Thanks Jim!

Klaas

On Oct 4, 2011, at 10:34 PM, Jim Schaad wrote:

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

---

From: Luke Howard <[email-masked]>
Date: Wed, 5 Oct 2011 19:00:55 +1100

> "smtp.example.com@SMTP" as a host name.  However this looks very strange to

[email-masked] would be correct, I agree this notation is confusing, given that most administrators are more familiar with the SPN notation used by Kerberos (smtp/smtp.example.com).

> auth at 0x1 rather than 0x2.

The flags are from RFC 2744 (e.g. GSS_C_MUTUAL_FLAG is 2). Whilst the initiator should only disclose flags that are relevant to completing the authentication, this allows for future expansion (for example, an initiator that supports DCE-style authentication might use this to select GSS_C_DCE_STYLE).

> further key derivation work?

I'm wondering actually whether should derive a new key and use RFC 3961 directly rather than GSS_GetMIC(). This might avoid some sequencing issues; the MIT Unwrap/VerifyMIC code checks sequence numbers within a window, and I'm wondering if there might be some attacks because of this. (Of course, this may just be an implementation bug, I need to do more research.)

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Wed, 05 Oct 2011 11:08:04 -0400

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

    Jim> Sam and Josh, I apologize; I have been going through unsent
    Jim> mail and other files where I make comments.  I had actually
    Jim> done most of a review, but had not completed it and therefore
    Jim> had not sent the review to the list.  I thought it was out but
    Jim> was in error, thus my earlier message.

    Jim> Jim

    Jim> 1.  In section 1.2, under what circumstances would an acceptor
    Jim> fail to respond to an initiator short of a transport failure?
    Jim> Can this ever happen in a success case?  If it cannot then I
    Jim> would suggest that /acceptor may respond/ be changed to
    Jim> /acceptor responds/ 

I've made the change.
Technically some protocols declare failure at a level higher than GSS
and abandon the authentication at the GSS layer.
In this case, the acceptor never responds at the gss layer ever though
gss has not failed.
However, I don't think this complexity is worth going into so I've
adopted your proposed change.

    Jim> I guess there would also be a question of
    Jim> the initial negotiation being anything other than
    Jim> query/response - for example an EAP retry would be sourced from
    Jim> the acceptor and might not be expected by the initiator.

EAP retries MUST never happen with gss-eap.
We don't seem to say that though.
I've added a sentence to that affect in 1.2.

    Jim> 2.  In section 1.2 para #2 - we have not established what the
    Jim> peer and authenticator are for EAP.  It would be a good idea to
    Jim> identify who is whom.  Suggest adding a sentence similar to the
    Jim> first sentence in the previous paragraph.

I did so, it's much more complicated though because of the split between
the passthrough authenticator and EAP server.

    Jim> 3. In section 1.2 - I have always been worried about the
    Jim> statement that EAP authentication can start w/ the peer, but
    Jim> the first message is always from the authenticator.  I believe
    Jim> that it would be more correct to state that EAP authentication
    Jim> always starts with the authenticator, but it may start with the
    Jim> peer for any given EAP mechanism.

No. What's meant by that statement is that either the peer or the
authenticator's lower layer machinery may trigger the EAP state machine
into action.
That always happens with the peer in our lower layer, so I'm removing
the statement.
I've also added a note that we need to  prod the EAP authenticator into
doing something to get things started.

    Jim> 4.  In section 1.2 - I would suggest that /GSS-API peer/
    Jim> becomes /GSS-API acceptor/ This keeps the term peer to be used
    Jim> only for EAP and only for the GSS-API initiator (possibly
    Jim> unless we are dealing with terms for an EAP pass-through
    Jim> system)

right.

    Jim> 5.  In section 1.2 - You say that the GSS-API acceptor acts as
    Jim> an EAP pass-through authenticator.  I am not sure if that means
    Jim> that the GSS-API acceptor needs to deal with the requirements
    Jim> for an EAP pass-through such as the fact that it is supposed to
    Jim> check the record value of EAP item rather than just pass-it
    Jim> through.

It should.

    Jim> 6. In section 3 - I have a real problem with the first sentence
    Jim> in the section.  I don't believe that it is a true statement.
    Jim> What is authenticated is going to be based on what the EAP
    Jim> method is and what is expected.  I have always assumed that it
    Jim> starts by authenticating a user to a realm as the single
    Jim> authentication and different things for mutual authentication.
    Jim> It might be that the sentence was supposed to be "EAP
    Jim> authenticates within a realm."
The sentence reads "EAP authenticates a user to a realm," now.

    Jim> 7. Is the BNF in section 3.1 supposed to ensure that a name
    Jim> cannot be "[email-masked]"?  Currently you would need to
    Jim> say "shartman/@janet.edu"

The BNF is wrong; I have review comments on this and will deal. Sorry
that failed to happen for the last update.

    Jim> 8.  In section 3.1 An example of a GSS_C_NT_HOSTBASED_SERVICE
    Jim> name would be useful for people w/o sufficient background.  I
    Jim> would need to look farther on this, but based on this text I
    Jim> would end up with something like "smtp.example.com@SMTP" as a
    Jim> host name.  However this looks very strange to me.

You'd actually have something like [email-masked] imported as
 GSS_C_NT_HOSTBASED_SERVICE would become smtp/example.com@ .Any chance
 you could provide example text that would clarify what you
 found confusing?

    Jim> 9.  In section 3.3 -- Which acceptor name must be sent in the
    Jim> AAA transport?  There are three different ones listed above, or
    Jim> this could be a completely different field.  It might also be
    Jim> that the portions are to be re-composed in order to send onto
    Jim> the client in the EAP channel, if this is the case then why do
    Jim> the decomposition?

You want to send all the non-empty portions.
The reason to decompose is to make life easier for proxies; different
portions are verified at different places.
Also, acceptors may not known their realm, but proxies may insert this.

    Jim> 10.  In section 3.3 - is the client signaling mutual
    Jim> authentication on the EAP channel or on the GSS-API channel?
GSS channel; clarified.

    Jim> 11. In section 5.5 - who does the initiator return the error
    Jim> message to?  What state should it transition to?  Should it
    Jim> still accept an error from the acceptor in the GSS-API
    Jim> protocol?

GSS_Init_Sec_context returns an error. I clarified no output token is
produced in this case.  That terminates the initiator state machine; the
context is invalid at that point according to 2743.

    Jim> 12.  In section 5.6 - It is not clear to me if one can progress
    Jim> from the Extension State to the Extension state rather than the
    Jim> completed state as part of negotiation of option features.  Is
    Jim> this something that needs to be clarified?
Not currently.

There is not currently a transition from extensions to extensions.
You could presumably include messages in earlier states as optional
 tokens indicating support for that and then include an extension that
 required that, but the current state machine does not support this.
I think we don't need the complexity now and I think it's sufficiently
future-proofed that we can get it when we need it.

    Jim> 13.  In Section 5.6.1 - is the flag bit of 0x1 reserved for
    Jim> some purpose?  If so this needs to be documented.  If not then
    Jim> why not start with mutual auth at 0x1 rather than 0x2.

These flags are intended to align with flags in RFC 2744 for convenience
of implementation.

    Jim> 14.  In section 5.6.3 - Do I assume that it is so obvious that
    Jim> it does not need to be stated that the EAP negotiated key is
    Jim> used for the MIC w/o any further key derivation work?

No; that's actually kind of non-sensical.
The EAP key is  a bit string.
GSS_GetMIC requires indirectly an RFC 3961 key.
The CRK is used.
I've added a reference.

    Jim> 15. In section 5.7 - I am not clear what set of channel binding
    Jim> data needs to be included in the EAP method.  Would this be
    Jim> data about the channel carrying the GSS-API methods or the
    Jim> GSS-API/AAA channel or both?  I assume this should really
    Jim> include channel data all the way from the acceptor to the EAP
    Jim> server but I don't know that.  How much does this differ from
    Jim> the acceptor name referenced in question 9?
It's exactly the same; there is already a reference to 3.3 in that
    Jim> paragraph.
What additional text would you like?

    Jim> Typos:

    Jim> s/thearchitecture/the architectural/ or /the architectures/
    Jim> s/authorisation/authorization/ - American English spellings
    Jim> preferred check if passthrough is a single word or should be
    Jim> pass-through.  My dictionary dislikes it as a single word.
    Jim> s/receievs/receives/ s/faris/far is/

fixed, thanks.

All appearing in the next update to be published within a week or two.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 05 Oct 2011 11:21:13 -0400

>>>>> "Luke" == Luke Howard <[email-masked]> writes:

    >> 14.  In section 5.6.3 - Do I assume that it is so obvious that it
    >> does not need to be stated that the EAP negotiated key is used
    >> for the MIC w/o any further key derivation work?

    Luke> I'm wondering actually whether should derive a new key and use
    Luke> RFC 3961 directly rather than GSS_GetMIC(). This might avoid
    Luke> some sequencing issues; the MIT Unwrap/VerifyMIC code checks
    Luke> sequence numbers within a window, and I'm wondering if there
    Luke> might be some attacks because of this. (Of course, this may
    Luke> just be an implementation bug, I need to do more research.)

I'd prefer an RFC 3961 getmic directly using the CRK and a new key
usage.
Rationale: makes prot_ready more possible if we ever want to do that.

I thought there was some reason you didn't want to do that though. I
thought I brought up using 3961 directly here.
Reauth?

---

From: Luke Howard <[email-masked]>
Date: Thu, 6 Oct 2011 02:35:23 +1100

> I'd prefer an RFC 3961 getmic directly using the CRK and a new key

Sounds good -- and simple to implement. If we do this for channel bindings too then we can allow the acceptor to ignore them without disturbing the sequence state. That avoids the overhead of sending a wrap token which we currently do. Can you propose some key usage numbers?

> thought I brought up using 3961 directly here.

No, the reason was I was hoping that it might be possible to reuse existing RFC 4121 implementations (e.g. on Windows). But I realise now that both options are equally (im)practical.

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Wed, 05 Oct 2011 13:18:48 -0400

>> I'd prefer an RFC 3961 getmic directly using the CRK and a new
    >> key usage.

    Luke> Sounds good -- and simple to implement. If we do this for
    Luke> channel bindings too then we can allow the acceptor to ignore
    Luke> them without disturbing the sequence state. That avoids the
    Luke> overhead of sending a wrap token which we currently do. Can
    Luke> you propose some key usage numbers?

Do we want our own key usage registry or do we want to use krb-wg's?  If
krb-wg's then I need to ask Tom Yu right now.  If we want our own we can
add a registry in gss-eap.

Using krb-wg's makes it very sure there won't be any attacks that
result.  However it's probably fine for us to use our own if we
guarantee that our key usages will only be used with keys that we get
from a GMSK rather than say from a KDC.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 5 Oct 2011 12:22:03 -0700

Emotionally I think that I would say take them from the krb-wg registry so
that they are not used there in the future which might lead to problems.

Logically, I don't think it matters.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Sam Hartman
> Sent: Wednesday, October 05, 2011 10:19 AM
> To: Luke Howard
> Cc: [email-masked]
> Subject: Re: [abfab] Review of draft-ietf-abfab-gss-eap-02
> 
> Using krb-wg's makes it very sure there won't be any attacks that result.
> However it's probably fine for us to use our own if we guarantee that our
key
> usages will only be used with keys that we get from a GMSK rather than say
> from a KDC.

---

From: Luke Howard <[email-masked]>
Date: Thu, 6 Oct 2011 09:00:57 +1100

> that they are not used there in the future which might lead to problems.

Well, there's already quite a lot of reuse in the krb-wg registry :-)

But sure, I agree. I'll ask Tom.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Thu, 6 Oct 2011 09:49:14 +1100

So, I propose that we replace the existing GSS channel binding and extension wrap/MIC tokens (respectively) with RFC 3961 checksums using the CRK with the following key usage numbers:

KEY_USAGE_CHANNEL_BINDINGS_MIC      TBD
KEY_USAGE_ACCEPTOR_TOKEN_MIC         TBD
KEY_USAGE_INITIATOR_TOKEN_MIC       TBD

A nice property of this is that we can efficiently deal with large GSS channel bindings (because we are sending a checksum rather than a wrap token; recall, we previously sent a wrap token so that the acceptor could ignore channel bindings without disturbing its sequence state).

Comments?

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Wed, 5 Oct 2011 17:57:38 -0500

> adopted your proposed change.

It would be more accurate to say that the GSS-API mechanism can fail
without a context token (a token which could only communicate the
error, and supplementary information) to send to the other side, and
that even when there is such an "error token" the application is not
required to send it.  Generally only the acceptor would produce an
error token.

However, it is good form for GSS mechanisms to both, specify and
output such error tokens.  It should be up to applications whether to
send them.  And, of course, applications must cope with errors that
come with no error token.

If EAP has no message suitable for constructing a GSS error token,
well, either GSS-EAP could specify one, or you could leave it
unspecified and c'est la vie.  But spell this out :)

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Thu, 6 Oct 2011 10:00:08 +1100

> unspecified and c'est la vie.  But spell this out :)

Well, we have errors at the GSS EAP layer anyway, so there is a GSS EAP error token. The draft just needs to be filled in with the minor status codes, which will be something like this.

error_code GSSEAP_WRONG_SIZE,                   "Buffer is incorrect size"
error_code GSSEAP_WRONG_MECH,                   "Mechanism OID is incorrect"
error_code GSSEAP_BAD_TOK_HEADER,               "Token header is malformed or corrupt"
error_code GSSEAP_TOK_TRUNC,                    "Token is missing data"
error_code GSSEAP_BAD_DIRECTION,                "Packet was replayed in wrong direction"
error_code GSSEAP_WRONG_TOK_ID,                 "Received token ID does not match expected token ID"
error_code GSSEAP_CRIT_ITOK_UNAVAILABLE,        "Critical inner token type unavailable"
error_code GSSEAP_MISSING_REQUIRED_ITOK,        "Missing required inner token"
error_code GSSEAP_DUPLICATE_ITOK,               "Duplicate inner token received"
error_code GSSEAP_WRONG_ITOK,                   "Recieved invalid inner token for current state"
error_code GSSEAP_KEY_UNAVAILABLE,              "EAP key unavailable"
error_code GSSEAP_KEY_TOO_SHORT,                "EAP key too short"
error_code GSSEAP_RADIUS_AUTH_FAILURE,          "Authentication rejected by RADIUS server"
error_code GSSEAP_UNKNOWN_RADIUS_CODE,          "Received unknown response code from RADIUS server"
error_code GSSEAP_MISSING_EAP_REQUEST,          "RADIUS response is missing EAP request"
error_code GSSEAP_RADIUS_PROT_FAILURE,          "Generic RADIUS failure"

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Wed, 5 Oct 2011 18:03:31 -0500

> A nice property of this is that we can efficiently deal with large GSS channel bindings (because we are sending a checksum rather than a wrap token; recall, we previously sent a wrap token so that…

Mostly only that I approve.

Note that if you really did want to use an RFC4121 per-msg token
library and still not get forced into sequencing you have two options
available:

a) there are no sequencing problems, since RFC4121 can handle
out-of-sequence tokens;
b) you could create separate "contexts" for internal each use of
RFC4121, with different keys in each case, all derived from the EAP
keys.

Now, RFC4121 is going to require RFC3961/2 anyways, so using RFC3961/2
directly in this part of GSS-EAP is hardly a burden -- unless you have
an API to the first but not the second...

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 5 Oct 2011 18:05:29 -0500

On Wed, Oct 5, 2011 at 6:00 PM, Luke Howard <[email-masked]> wrote:
> Well, we have errors at the GSS EAP layer anyway, so there is a GSS EAP
> error token. The draft just needs to be filled in with the minor status
> codes, which will be something like this.

Minor status codes don't really have to be defined, IMO, though it
certainly doesn't hurt to do so -- particularly if there's something
an application can do to recover from a specific error.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Thu, 6 Oct 2011 10:08:55 +1100

> a) there are no sequencing problems, since RFC4121 can handle

Hmm. I'm not convinced that this wouldn't have created other problems, I need to think about it some more.

> RFC4121, with different keys in each case, all derived from the EAP

Yes, this would have worked, although using usage numbers and 3961 is a little easier from an implementation perspective (you only have one derived key to manage).

> an API to the first but not the second...

Well, there is an API for RFC4121. But there's no clear way to manufacture a context purely in order to use its cryptographic services. (e.g. you could import a fake context, but you'd have to understand its contents, which are implementation dependent.) So I think it's 6 of one, half a dozen the other.

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Wed, 5 Oct 2011 18:13:18 -0500

> Hmm. I'm not convinced that this wouldn't have created other problems, I need to think about it some more.

Well, if you can guarantee that all per-msg tokens will have been
processed by the time you're ready to handle the app's tokens...  Ah,
now I understand Sam's comment about PROT_READY.

> Yes, this would have worked, although using usage numbers and 3961 is a little easier from an implementation perspective (you only have one derived key to manage).

Yes, which is why I agree with the proposal :)

> Well, there is an API for RFC4121. But there's no clear way to manufacture a context purely in order to use its cryptographic services. (e.g. you could import a fake context, but you'd have to unde…

We ought to define a subset of RFC4121 exported sec contexts for the
purpose of using it as a per-msg token library!  :)

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Thu, 6 Oct 2011 11:11:54 +1100

> an application can do to recover from a specific error.

If they are on the wire...

---

From: Nico Williams <[email-masked]>
Date: Wed, 5 Oct 2011 19:33:33 -0500

> If they are on the wire...

Oh, heh, sure.  Excuse my silliness.

---

From: Luke Howard <[email-masked]>
Date: Fri, 7 Oct 2011 01:21:29 +1100

If we are going to make this change, maybe we should change the derivation salt for the CRK to "rfc3961-gss-eap". Or is this too pedantic. 

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Thu, 06 Oct 2011 12:27:04 -0400

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

    Nico> On Wed, Oct 5, 2011 at 10:08 AM, Sam Hartman
    Nico> <[email-masked]> wrote:
    >>    Jim> 1.  In section 1.2, under what
    >> circumstances would an acceptor    Jim> fail to
    >> respond to an initiator short of a transport failure?   
    >> Jim> Can this ever happen in a success case?  If it cannot
    >> then I    Jim> would suggest that /acceptor may
    >> respond/ be changed to    Jim> /acceptor responds/
    >> 
    >> I've made the change.  Technically some protocols declare failure
    >> at a level higher than GSS and abandon the authentication at the
    >> GSS layer.  In this case, the acceptor never responds at the gss
    >> layer ever though gss has not failed.  However, I don't think
    >> this complexity is worth going into so I've adopted your proposed
    >> change.

    Nico> It would be more accurate to say that the GSS-API mechanism
    Nico> can fail without a context token (a token which could only
    Nico> communicate the error, and supplementary information) to send
    Nico> to the other side, and that even when there is such an "error
    Nico> token" the application is not required to send it.  Generally
    Nico> only the acceptor would produce an error token.

While this is a true statement, it's independent of what I was getting
at.  My statement still stands. Some protocols decide to abandon a gss
authentication progress for their own reasons.
It's also true that gss mechanisms fail.

Luke has already pointed out we have an error token.  It's described in
the draft; the registry of values to go in it not yet.

---

From: Nico Williams <[email-masked]>
Date: Thu, 6 Oct 2011 11:54:05 -0500

On Thu, Oct 6, 2011 at 11:27 AM, Sam Hartman
<[email-masked]> wrote:
>    Nico> can fail without a context token [...]
>

Agreed.  I must have misunderstood you then.  Apologies for the noise.

Nico
--

---

From: Luke Howard <[email-masked]>
Date: Fri, 7 Oct 2011 08:32:55 +1100

OK, I have another question relating to possibly using RFC 3961 checksums.

Currently the GSS channel binding token from the client is marked critical, i.e. the acceptor expects it to be there (regardless of whether it has channel bindings or not). This is because the acceptor's behaviour is GSS_Unwrap() and compare, to keep its sequence number in sync with the initiator.

If we switch to a MIC, can we just omit the channel binding token in the case the client has no channel bindings? The exchange that contains the channel binding token is itself protected by a MIC, so an attacker cannot remove it. The acceptor would need to raise an error if no binding token was provided and the caller of GSS_Accept_sec_context() indicated bindings.

-- Luke

--
Luke Howard / [email-masked]
www.padl.com / www.lukehoward.com

---

From: Luke Howard <[email-masked]>
Date: Fri, 7 Oct 2011 08:41:46 +1100

> If we switch to a MIC, can we just omit the channel binding token in the case the client has no channel bindings? The exchange that contains the channel binding token is itself protected by a MIC,…

... although this itself could be configurable with a context option to allow missing bindings.

-- Luke

---

From: Luke Howard <[email-masked]>
Date: Fri, 7 Oct 2011 09:24:01 +1100

5.6.1 says the flags subtoken contains a bit "indicating that the acceptor successfully performed mutual authentication". Is it not the initiator that is indicating this?

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Tue, 18 Oct 2011 14:30:01 -0400

>>>>> "Luke" == Luke Howard <[email-masked]> writes:

    Luke> 5.6.1 says the flags subtoken contains a bit "indicating that
    Luke> the acceptor successfully performed mutual authentication". Is
    Luke> it not the initiator that is indicating this?  -- Luke

fixed, thanks.

---

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

>> If we switch to a MIC, can we just omit the channel binding token
    >> in the case the client has no channel bindings? The exchange that
    >> contains the channel binding token is itself protected by a MIC,
    >> so an attacker cannot remove it. The acceptor would need to raise
    >> an error if no binding token was provided and the caller of
    >> GSS_Accept_sec_context() indicated bindings.
    Luke> ... although this itself could be configurable with a context
    Luke> option to allow missing bindings.

If you want to work with HTTP, you want to ignore channel bindings if
the acceptor passes in null.

---

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

>>>>> "Luke" == Luke Howard <[email-masked]> writes:

    Luke> If we are going to make this change, maybe we should change
    Luke> the derivation salt for the CRK to "rfc3961-gss-eap". Or is
    Luke> this too pedantic.  -- Luke

I'd actually prefer to keep the derivation salt as RFC 4121 because I
believe it's more correct.  In terms of per-message processing which is
most of what the CRK is used for, it is RFC 4121.