Subject: Re: [Ietf-krb-wg] PROTO review of draft-ietf-krb-wg-gss-cb-hash-agility-03.txt

From: Shawn M Emery <[email-masked]>
Date: Sun, 13 Jul 2008 02:56:38 -0600

Larry Zhu wrote:
> The following are my review comments on draft-ietf-krb-wg-gss-cb-hash-agility-03.txt. These were produced while completing my PROTO write-up as the PROTO shepherd of this document.
>   

Larry, thanks for the review.  Sorry for the long delay, I was working 
on an interop project, as you may already know.

My comments in-line...

> I have a total of 17 comments. Except comment 2 and 16, please treat them as from an individual.  Naturally, I'd like to see them all addressed, but particularly I believe that the items mentioned in comments 1, 8, 12, 14, and 16, 6 should be addressed before moving forward.
>
>
> 1. in the abstract, the terminology is inconsistent with RFC2743.
>
>    Currently, the Kerberos Version 5 Generic Security Services
>    Application Programming Interface (GSS-API) mechanism [RFC4121] does
>    not have the ability to utilize better hash algorithms used to
>    generate channel binding identities. ...
>
>  RFC2743 describes channel bindings as relevant characteristics, not "identities". I suggest the following text.
>
>    Currently, channel bindings are implemented using a MD5 hash in the Kerberos Version 5 Generic Security Services
>    Application Programming Interface (GSS-API) mechanism [RFC4121]. This document updates RFC4121 to allow
>    the channel binding restriction to be carried using algorithms negotiated based on Kerberos crypto framework as defined in RFC3961.
>    In addition, because this update makes use of the last extensible field in the Kerberos client-server exchange
>    message, extensions are defined to allow future protocol extensions.
>
> 2. in the abstract. Nits.
>
> It needs to mention it updates RFc4121.
>   

I agree with the update to the abstract, with just a couple of rewordings.

> 3, Section 1. Nits.
>   " With the recently discovered weaknesses in the MD5 hash algorithm
>    there is a need to move stronger hash alogrithms."
>
> There are two problems in this sentence:
>
>  alogrithms should spell algorithms.
>
>   s/move/use/
>   

Done.

> 4. various portions in section 1. Same as comment #1.
>
> Channel bindings are restrictions against reuse of the authentication tokens, they are not identities.
>
> Quote from RFc2743,
> "The GSS-API accommodates the concept of caller-provided channel
>    binding ("chan_binding") information.  Channel bindings are used to
>    strengthen the quality with which peer entity authentication is
>    provided during context establishment, by limiting the scope within
>    which an intercepted context establishment token can be reused by an
>    attacker. Specifically, they enable GSS-API callers to bind the
>    establishment of a security context to relevant characteristics
>    (e.g., addresses, transformed representations of encryption keys) of
>    the underlying communications channel, of protection mechanisms
>    applied to that communications channel, and to application-specific
>    data."
>   

Characteristics define the identify the communications channel, but I'm 
not going to argue too hard against this request.  Done.

> 5. section 1, nits.
>
> Kerberos Version 5
>    Generic Security Services Application Programming Interface (GSS-API)
>    mechanism [RFC4121] uses MD5 to calculate channel binding identities
>    that are required to be unique.
>
> It is unclear to me why the uniqueness is required. I suggest
>
>    Kerberos Version 5
>    Generic Security Services Application Programming Interface (GSS-API)
>    mechanism [RFC4121] uses MD5 to compute channel binding verifiers.
>   

Done.

> 6. section 1, nits.
>
>   This will prevent lengthy
>    standardizations in the future when new attacks arise and will allow
>    an incremental update to the protocol so that this will interoperate
>    with older implementations.
>
> I do not agree with this prevents standardizations. I suggest
>   

Perhaps you're misinterpreting what I'm saying here, which may mean it's 
not clear to everyone.

>   This will allow deploying newer algorithms incrementally without breaking the interop with older implementations, when new attacks arise in the future.
>   

Done.

> 7. section 3. Nits.
>
> Replace the "identifier" with "verifier".
>   

Done.

> 8. section 3, it says "TYPED_DATA", but the description immediately after it saying a totally different  encoding.
>   

Ok, I'll remove the length specifier then.

> 9. section 3, the indenting of the following text is funny, can you check?
>
>   where Exts is the concatenation of zero, one or more individual
>       extensions, each of which consists of:
>         type -- big endian order unsigned integer, 32-bits
>         length -- big endian order unsigned integer, 32-bits
>         data -- octet string of length octets
>       in that order
>   

Done.

> 10. Section 3, the GSS-checksum type does not have anything new till the "Exts" field from RFC4121. Can you clarify this?
>   

How about something like this?:

... In addition, initiators MUST populate the extension field, Exts, 
with TYPED-DATA as defined in "RFC4120.  Nothing before the Exts field 
is different from what is defined in RFC4121.  The 0x8003 GSS checksum...

> 11. section 3,  'octet string of length octets", I found this hard to read, how about "extension data encoded as a stream of octets"?
>   

Irrelevant, see above (TYPED-DATA).

> Can you add a structure definition so that this is easier to refer to.
>
> Can you change the description of the "length" to
>
> length -- big endian order unsigned integer, 32-bits, this contains the length of the extension data in octets.
>
> And change the description of the "type" to
>
> type -- big endian order unsigned integer, 32-bits, this contains the type of the extensions.
>   

More text is fine by me, done.

> 12. section 3, can you add "there must be at most one instance of a given instance type". This simplifies processing of the extensions.
>   

Hmmm, I use the word individual extensions.  But I'll add an additional 
note at the end of the section.

> 13. section 3, the following text is imprecise.
>
>   Initiators that are unwilling to use a MD5 hash of the channel
>    bindings should set the Bnd field to all ones (1).
>   

The fields are defined as octets, which to me, equates to 16 octets set 
to "all ones" (=0xFF)

> An implementer would interpret this to 16 bytes of ones, vs 16 bytes of 0xFF.
>   

Ok, how about?:  ...MUST set the Bnd field to sixteen octets of hex 
value FF.

> And change "should" to all upper case "MUST".
>   

Done.

> 14. section 6, this section must have meaningful exploration of security issues raised by the proposal. In particular the solution is incomplete. if the client does not send the get_mic channel binding, can you define an error to return to the application? This is because in your security considerations section, you

If the application requires that the acceptor verify the channel 
bindings and this does not match expectations then the API will return 
GSS_S_BAD_BINDINGS?  Why does this need to change or be reiterated here?

> specify "it is up to applications to decide", but you did not define a way to allow the applications know what happens (then how can they decide?).
>   

This is already discussed in 2743; if the caller expects channel binding 
verification and it doesn't meet this requirement then an error 
indicator is returned.  The application is responsible for deciding if 
channel binding is required.

> 15. please update "TBD" key usage number since it is already assigned.
>   

.. after this revision was published :)

> 16. update the number assignment policy in the Section 5 per Vancouver meeting/consensus.
>   

Yes, but I didn't receive a response from my e-mail on the proposed 
assignments, which were:

   Adhering to the policies outlined in [RFC2434], type number allocations are as                              
   follows:

	0x00000000 - 0x000003FF    IETF Consensus
	0x00000400 - 0xFFFFF3FF    Specification Required
	0xFFFFF400 - 0xFFFFFFFF    Private Use

> 17. section 5, the verifier for the channel bindings is not always computed with a hash function. RFC3961 does not define a hash in the generic profile. I suggest, replace OLD
> "Extension for hash function-agile channel binding," with "Extension for the verifier of the channel bindings,"
>   

Yes, I guess it does not preclude the use of a hash, it could be just 
data :)  Done.

Shawn.
--
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 Jul 2008 21:08:25 +0200 (MEST)

There are a number of problems with GSS-API channel bindings which have
been making their use somewhat unattractive.

The most significant problem is that there is a large installed base
of Kerberos mechanisms that doesn't implement them (doesn't support
them at the API level).

Then there is the problem that there is no negotiation about the
use of channel bindings.  If initiator and acceptor do not both
supply the exact same type and same value of the channel bindings,
the security context establishement will fail.

The other very serious problem with channel bindings is that they
usually do not get along with firewall traversal.  This may be less
of a problem with Kerberos environments, because Kerberos itself
breaks horribly in firewalled environments, but for less handicapped
gssapi mechanisms, channel bindings would be very counterproductive,
so they're often _not_ used/asserted on purpose.

Im not a Kerberos protocol wrangler, so I don't know how obvious/clear
it is to an implementor when draft-ietf-krb-wg-gss-cb-hash-agility-04.txt
talks about "Kerberos V get_mic()" -- that this does not refer to
the GSS-API get_mic() message protection service?
(because the latter usually includes messsage sequence protection,
 which would interfere with a fallback to the old scheme).

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Jul 2008 14:18:50 -0500

> of Kerberos mechanisms that doesn't implement them (doesn't support

Let's grant that, for the sake of argument.  So what?

> the security context establishement will fail.

Indeed.  Use of channel bindings, and their negotiation, requires
changes to application protocols.  This does not mean that channel
binding is useless.

> usually do not get along with firewall traversal.  This may be less

No, that's not true of channel binding in the RFC5056 sense -- only when
using network addresses as channel bindings is your assertion true.

> the GSS-API get_mic() message protection service?

It refers to the RFC3961 get_mic() function.

>  which would interfere with a fallback to the old scheme).

Nico

---

From: Larry Zhu <[email-masked]>
Date: Tue, 29 Jul 2008 04:54:06 -0700

> I agree with the update to the abstract, with just a couple of rewordings.

The updated text says:

  This document updates
  RFC4121 to allow the channel binding restriction to be lifted

I disagree with the use of words "lifted". We apply restrictions to the GSS-API tokens using channeling bindings. It sounds opposite to "lifted", doesn't it?

Also the encoding of -04 is not clear to me.

Thx,

--larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Sunday, July 13, 2008 1:57 AM
To: Larry Zhu
Cc: [email-masked]
Subject: Re: PROTO review of draft-ietf-krb-wg-gss-cb-hash-agility-03.txt

My comments in-line...

Done.

Done.

Done.

Done.

Done.

Done.

Shawn.
--

---

From: "Shawn M. Emery" <[email-masked]>
Date: Thu, 31 Jul 2008 09:06:13 -0600

> I disagree with the use of words "lifted". We apply restrictions to the GSS-API tokens using channeling bindings. It sounds opposite to "lifted", doesn't it?

No, lifted in relation to the restriction.  How about?:

...This document updates RFC4121 to allow the channel binding 
restriction to be eliminated using algorithms negotiated based on 
Kerberos crypto framework as defined in RFC3961...

> Also the encoding of -04 is not clear to me.

I removed the reference to TYPE-DATA (viz 4120).

Shawn.
--

---

From: Larry Zhu <[email-masked]>
Date: Thu, 31 Jul 2008 08:15:49 -0700

[email-masked] wrote:
> ...This document updates RFC4121 to allow the channel binding restriction to be eliminated
> using algorithms negotiated based on Kerberos crypto framework as defined in RFC3961...
This is rather long and hard to parse, how about simply

...This document updates RFC4121 to allow channel bindings using algorithms negotiated based on Kerberos crypto framework as defined in RFC3961...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 31, 2008 8:06 AM
To: Larry Zhu
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] PROTO review of draft-ietf-krb-wg-gss-cb-hash-agility-03.txt

Shawn.
--