Subject: [abfab] gss-eap: empty channel bindings

From: Sam Hartman <[email-masked]>
Date: Fri, 06 Apr 2012 16:12:21 -0400

Hi folks.

I noticed that under the current draft a mechanism should use the RFC
3961 GetMIC operation on an empty token buffer if an application passes
in NULL channel bindings to gss_init_sec_context.

I also noticed that this is not what the Moonshot code does.
Instead, the moonshot code  skips the channel binding subtoken entirely
if the application passes in no channel bindings.

RFC 3961 says that you can pass in any length data to that operation,
which presumably includes 0.  I think our checksums are well-defined for
0-length inputs.  It's not a widely tested code path, but it probably
works and we can work through any bugs relatively quickly. Greg Hudson
at MIT did check the aes128 code path and that seems to work.

On the other hand, I think what the Moonshot code does is secure.  If an
attacker removes a channel bindings subtoken the MIC token should detect
this.

My assumption is that unless there's a consensus to change the draft
should remain as-is and Moonshot should change its code.
However I'd like to call out the issue and get opinions on whether we
want to:

1)  Send a MIC of a empty buffer

or
2) Omit the token entirely

As far as I can tell 1 exercises a not-often-used code path, but is
probably fine and 2 is probably fine.

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 6 Apr 2012 22:51:41 -0400

> at MIT did check the aes128 code path and that seems to work.

It does say "any length".  On the other hand, we did explicitly rule out empty messages for encryption, and I don't recall whether we thought as hard about the checksum case.

I don't think des-mac-k is well-defined for a zero-length message.  For a zero-length message, the length is a multiple of 8 octets, so no padding bytes are added.  With a zero-length input, we get zero bytes out of the CBC-mode encryption… and then we're supposed to use the last block of that output as the MIC.  However, it was described as "no longer recommended" even in RFC 1510, and between that and the des-die-die-die draft, I'm not inclined to worry about it too much.

The rest appear to support zero-length messages.

It's something to keep in mind for 3961bis. :-)

Ken

---

From: Sam Hartman <[email-masked]>
Date: Mon, 09 Apr 2012 13:34:43 -0400

After reading Luke's mail and Ken's mail my preference is to chang ethe
draft to do what the Moonshot code does.  In particular I propose that
the channel binding code is critical but not required.  It MUSt be sent
when non-empty application channel bindings are passed in and MUST NOT
be sent when empty application channel bindings are passed into
gss_init_sec_context.

I'd appreciate someone besides me analyzing the protocol and confirming
that doing this is secure.

I think that leaves Luke, Ken and I preferring a change and no other
opinions expressed so far.

I'm holding we can fold a decision on this into a last call.