Subject: [Gen-art] Gen-ART LC review of draft-ietf-kitten-gssapi-channel-bindings-05.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 03 Nov 2008 11:10:20 +1300

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 3 Nov 2008 02:47:02 -0600

On Mon, Nov 03, 2008 at 11:10:20AM +1300, Brian E Carpenter wrote:
> Comments: 
> 
>    Here, then, is a generic re-statement of this structure, in pseudo-
>    ASN.1:
> 
> What's pseudo-ASN.1? This is normative, so why isn't it ASN.1?

RFC2743 lays out the *abstract* API for "generic security services".

RFC2743 uses "pseudo-ASN.1".

I kept the style of RFC2743.

> I can't parse this sentence:
> 
>    Where a language binding of the GSS-API models channel bindings as
>    OCTET STRINGs (or the language's equivalent), then the implementation
>    MUST assume that the given bindings correspond only to the
>    application-data field of GSS-CHANNEL-BINDINGS as shown above, rather
>    than some encoding of GSS-CHANNEL-BINDINGS.
> 
> 1. Is the 'as' supposed to mean 'only as'? 

More like "as a single OCTET STRING".

> 2. Why is this restricted to the application-data field? Why doesn't
> it also cover the various address fields? (OK, there's a clue hidden
> in the Security Considerations, but the explanation belongs here.)

Because RFC2743 said "OCTET STRING" and later RFC2744 imposed structure
without specifying an encoding of that structure to an OCTET STRING.

That's an old screwup.

Now, if anyone had built a language binding based strictly on RFC2743
then they'd have only an OCTET STRING input.  What to do?  Well, since
those "network addresses" in the RFC2744 channel binding structure
turned out to be utterly useless[*] and since such a language binding
would not have intended for network-addresses-as-channel-bindings, the
simplest choice is as given above.

> 3. Maybe I'm lacking context, but the 'rather than' clause doesn't make 
> sense to me at all. 

I think it can be removed.  Also, I suppose the MUST should be a SHOULD.

> Now, if what this is actually saying is that "Where a language binding
> does not support a SEQUENCE (or the language's equivalent)..."
> I could make some sense of it. But then the (pseudo) ASN.1 would need
> to be different, since the address fields would be absent.

The pseudo-ASN.1 sequence applies to language bindings that conform to
this document.  Pre-RFC2744 language bindings would likely have a single
octet string input argument for channel bindings, and the above sentence
states that for those "legacy" bindings this octet string input argument
corresponds to the application-data field of the pseudo-ASN.1 sequence.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 3 Nov 2008 10:47:15 -0600

> simplest choice is as given above.

I left out the footnote I'd intended to add:

[*] The only GSS-API application to use network addresses as channel
    bindings that I know of _was_ the MIT krb5 ftp/ftpd.  And it didn't
    use them for the main purpose of channel bindings (which is to
    detect MITM, and if there isn't one, defer session protection to
    lower-layer channel).  Instead the MIT krb5 ftp/ftpd use of network
    addresses as channel bindings simply made it impossible to traverse
    NAT.

    Now, NAT is an MITM, but it's one everyone wants to successfully
    traverse, and one which does not compromise any end-to-end security
    protocols (IPsec, TLS, SSHv2, ...).

    The thing is that network addresses as channel bindings provide no
    security unless coupled with IPsec, but that coupling would be very
    loose: the application has no idea whether it's there at all, not
    without checking local IPsec configuration.  Which is why we're
    pursuing draft-ietf-btns-connection-latching (IPsec channels), BTNS
    itself, and true cryptographic channel bindings for IPsec channels.
_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 3 Nov 2008 10:58:56 -0600

> I kept the style of RFC2743.

I should add a bit more about RFC2743 here.

RFC2743 uses pseudo-ASN.1 for two distinct things:

 - To specify a small amount of on-the-wire bits.

   For this true ASN.1 and DER would have been better, of course.

 - To specify the types of function input arguments and output results.

   RFC2743 uses only "scalar" (in the Perl5 sense) or simple (in the
   ASN.1 sense) types.  Everything's an OCTET STRING, an OBJECT
   IDENTIFIER, an INTEGER, or some type made up for RFC2743 (e.g.,
   CREDENTIAL HANDLE).

   RFC2744 changed the type of one argument, channel bindings, to be
   structured, no longer scalar.

This I-D uses pseudo-ASN.1 to model that now-structured view of channel
bindings imposed by RFC2744.  This I-D also provides an encoding for
this structure, but the encoding is not a ASN.1 encoding (not BER, DER,
CER, PER nor XER).  The chosen encoding (from RFC1964/RFC4121) is not
one of the standard encoding rules of ASN.1 because there already exist
implementations of the chosen encoding -- we're promoting code re-use.

Mechanism designers are, however, left to choose their own encoding if
they don't like the one from RFC1964/RFC4121.

Nico

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Nov 2008 09:13:29 +1300

Nico,

I understand your explanations on both of my comments, so my
summary is that the text in the draft is not quite clear enough
for a newcomer to the issue. While that is often the case for
technical documents, I think another couple of sentences
culled from your explanations would make the draft more robust.
(Especially since the point of the draft is to clarify something
that was left unclear by the previous RFCs.)

Thanks
   Brian

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 3 Nov 2008 16:49:07 -0600

> that was left unclear by the previous RFCs.)

I'll write up some additional introductory text.

Thanks!