Subject: Re: channel bindings and address types

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 25 Jun 2009 11:33:27 -0400

--On Thursday, June 25, 2009 04:54:40 PM +0200 Simon Josefsson 
<[email-masked]> wrote:

> I'm working on GS2 and thinking about how the GSS-CHANNEL-BINDING
> structure should be used.  In particular, I'm thinking of how to set the
> address type fields in an implementation, quoting RFC 5554:
>
> GSS-CHANNEL-BINDINGS ::= SEQUENCE {
>               initiator-address-type  INTEGER,      -- See RFC2744
>               initiator-address       OCTET STRING, -- See RFC2744
>               acceptor-address-type   INTEGER,      -- See RFC2744
>               acceptor-address        OCTET STRING, -- See RFC2744
>               application-data        OCTET STRING  -- See RFC5056
>       }
>
> The values for the initiator-address-type and acceptor-address-type
> fields are specified Appendix A of RFC 2744.  However, that is C
> specific.  I can't find anything in RFC 2743 about the address types.
> As far as I can tell, RFC 5554 does not improve this situation?

It does, if you read enough of it.  Basically, it points out that even 
though some of the API bits are in 2744, they're actually not C-specific, 
and it also points out that the encoding of channel bindings on the wire is 
specific to the mechanism; RFC4121 defines an encoding for Kerberos but not 
for other mechanisms.  It also refers specifically to RFC2744 for the 
values of the address-type fields.

Furthermore, one of the bullet points in section 5.1, starting at the 
bottom of page 13 in scram-01, makes it clear that we hash only the 
external channel type and binding data; that is, SCRAM ignores the address 
fields in the RFC2743/2744/5554 channel binding structure.  This is 
reasonable -- binding to IP addresses not only provides little security 
benefit but is actively harmful.  GS2 should simply set the address types 
to 0 and the strings empty, using only the application-data field as 
described in RFC5554.

-- Jeff

> I suggest we update RFC 2743/5554 and define symbols for GSS_C_AF_INET
> etc in a implementation independent way.

No.

> Further, there are no address type value allocated for IPv6 address as
> far as I can see?
>
> I think SCRAM/GS2 needs to be able to support IPv6 end points.

It needs to not try to represent addresses in channel bindings.

-- Jeff