Subject: Re: [abfab] Message Integrity for gss-eap

From: Sam Hartman <[email-masked]>
Date: Thu, 21 Apr 2011 09:03:32 -0400

I'd like to circle back to this conversation.

I don't think there seemed to be any clear winners on the technical
front.

As a comment to Luke, in your comment that RFC 3961 implies a hash
function with the mandatory to implement checksum, that's not really
true. It happens to be true for the existing enctypes we care
about. However an enctype could use a CBC-MAC (or other modern
crypto-based MAC) which cannot work at all without a key and for which
you cannot perform the iteration prior to the key.
So, if we go with the just use a hash option, we do need to negotiate it
in our OID at least sometimes.

The one option I don't have a good understanding of is the option where
we expect extensions to offer a MIC themselves.
In this option, each extension token needs to provide any needed
protection itself. There is no protection for the conversation as an
aggregate; only its parts.
This can provide the same level of security; it just makes our job in
the IETF harder in terms of doing security review.

I'd like to ask some questions:

1) Are we willing to tightly control what extension tokens their are?
I.E. do we think standards action or IETF review  are appropriate
registration policies for extensions?

2) What extensions needing MICs have we identified?
Is the mutual flag the only one?
We'd presumably also need protection of removed extensions; we could MIC
a list of token types sent.

--Sam

3) It's my belief that if we protect against removed extension tokens,
we can add a conversation level finish message later if we wish. If we
chose to do so in a backward compatible way, then we would not be able
to have a hash function identifier in the OID.
We could have a hash function in the extension token identifier though.
Can I get people who understand the technical details in sufficient
detail to sanity check me here and confirm that we could add
conversation-level protection later if we chose?

Thanks,

--Sam

---

From: Luke Howard <[email-masked]>
Date: Thu, 21 Apr 2011 18:57:56 +0200

> Is the mutual flag the only one?

* Server name indication
* Channel bindings (if we were to send the bindings themselves unprotected -- not that I'm suggesting that's something we wish to do)

In the future, possibly:

* Extension type negotiation

-- Luke

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 21 Apr 2011 17:47:49 -0700

> I.E. do we think standards action or IETF review  are appropriate
registration
> policies for extensions?
> We'd presumably also need protection of removed extensions; we could
> MIC a list of token types sent.

Some type of extension that allows for validation of external negotiation
(i.e. what I send to the RP before setting up the gss-eap session)?

> 
> --Sam
> 
> 3) It's my belief that if we protect against removed extension tokens, we
can
> add a conversation level finish message later if we wish. If we chose to
do so
> in a backward compatible way, then we would not be able to have a hash
> function identifier in the OID.
> Can I get people who understand the technical details in sufficient detail
to
> sanity check me here and confirm that we could add conversation-level
> protection later if we chose?
> 
> Thanks,
> 
> --Sam
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Sam Hartman <[email-masked]>
Date: Thu, 21 Apr 2011 20:31:16 -0400

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

    Jim> Some type of extension that allows for validation of external
    Jim> negotiation (i.e. what I send to the RP before setting up the
    Jim> gss-eap session)?

You can fold that into channel bindings if you like.
If you want something more than channel bindings I'm not aware of
anything that GSS-API gives you.

I think there are a lot of reasons we should not support things that GSS
cannot do in our GSS mechanism.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 26 Apr 2011 21:12:41 -0700

> -----Original Message-----
> From: Sam Hartman [mailto:[email-masked]]
> Sent: Thursday, April 21, 2011 5:31 PM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: Re: [abfab] Message Integrity for gss-eap
> 
> If you want something more than channel bindings I'm not aware of anything
> that GSS-API gives you.
> 
> cannot do in our GSS mechanism

I was not sure if this would be the type of thing that you wanted to put in
as an extension or not.

Jim

.