Subject: channel bindings and address types

From: Simon Josefsson <[email-masked]>
Date: Thu, 25 Jun 2009 16:54:40 +0200

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?

The conclusion appears to be that there are no implementation-agnostic
definition of the address type values?

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

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.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 25 Jun 2009 10:15:42 -0500

On Thu, Jun 25, 2009 at 10:13:13AM -0500, Nicolas Williams wrote:
> On Thu, Jun 25, 2009 at 04:54:40PM +0200, Simon Josefsson wrote:
> These are OPTIONAL, or should have been marked as such.  See RFC2744.

To be more specific, they are NOT OPTIONAL in the ASN.1 sense -- they
must be present -- but they can be GSS_C_AF_UNSPEC and the empty octet
strings.

GS2, specifically, MUST set the *-address-type fields to GSS_C_AF_UNSPEC
and the *-address fields to the empty octet string.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 25 Jun 2009 17:51:53 +0200

> and the *-address fields to the empty octet string.

I agree and this approach avoids the entire problem, and the potential
NAT problem as well.  Case closed, and sorry about the noise.

It still seems useful to update GSS-API to support IPv6 address types,
though.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 25 Jun 2009 10:13:13 -0500

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 25 Jun 2009 10:56:35 -0500

> It still seems useful to update GSS-API to support IPv6 address types,

Complete? yes, useful? no.

As you surmised, NAT and the *address* fields in there don't mix.  Even
without NAT (and no, IPv6 does not mean no NAT, sadly) binding in the
network addresses provides no additional security unless IPsec is in use
and provides a tight IP address <-> peer ID binding.  To really add
security you should do channel binding to IPsec channels, and that looks
much the same as channel binding to TLS.  (For more about IPsec channels
see the BTNS WG.)  So, in the end binding to addresses is just not very
useful.

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 25 Jun 2009 12:11:03 -0400

> definition of the address type values?

I think it's pretty obvious that all implementations need to use the  
same values regardless of implementation language or operating  
systems.  It's a little messy that they're specified in C rather than  
abstractly, but they are specified.  RFC 5554 does make it explicit  
that the C bindings specify how the content is defined, and explicitly  
says so for the address fields; I don't think it needs to explicitly  
restate it for address type fields.

> etc in a implementation independent way.

I'm not sure it's needed, but it wouldn't hurt anything, either.

> Further, there are no address type value allocated for IPv6 address as

Not officially.  MIT doesn't implement it, but Heimdal appears to use  
24 for GSS_C_AF_INET6.

-- 
Ken Raeburn / [email-masked] / no longer at MIT Kerberos Consortium

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Thu, 25 Jun 2009 09:28:06 -0700

> It still seems useful to update GSS-API to support IPv6 address types,

Heimdal uses

#define GSS_C_AF_INET6	    24

and store in the same way as v4 keys are stored.

Love

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 25 Jun 2009 13:43:37 -0400

--On Thursday, June 25, 2009 10:56:35 AM -0500 Nicolas Williams 
<[email-masked]> wrote:

>> > GS2, specifically, MUST set the *-address-type fields to
>> > GSS_C_AF_UNSPEC and the *-address fields to the empty octet string.
>>

Personally, I believe that for some time it has been the consensus of the 
GSS-API community that binding to addresses is not useful and should be 
avoided and treated as a deprecated feature.

Note, however, that I am not chair of the KITTEN working group.

-- Jeff

---

From: Shawn M Emery <[email-masked]>
Date: Fri, 26 Jun 2009 01:29:25 -0600

Jeffrey Hutzelman wrote:
> Personally, I believe that for some time it has been the consensus of 
> the GSS-API community that binding to addresses is not useful and 
> should be avoided and treated as a deprecated feature.
>

RFC 5554 states that network address as channel bindings is not very 
secure, which the chair would imply as not being very useful.

Shawn.
--

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 27 Jun 2009 18:39:21 +0200

> secure, which the chair would imply as not being very useful.

Where does it say that?  This part

   Language bindings that use OCTET STRING (or equivalent) for channel
   bindings will not support the use of network addresses as channel
   bindings.  This should not cause any security problems, as the use of
   network addresses as channel bindings is not generally secure.

appears to me imply that network address alone is not secure as a
channel binding, but that isn't the same.

If there is something inherent insecure about using network addresses in
channel bindings, I'd like to understand more.

As far as I can tell, there is no security problem in using network
addresses in channel bindings.  There is the obvious and major
deployment problem wrt NAT-like situations though.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 28 Jun 2009 00:07:39 -0500

> channel binding, but that isn't the same.

How is the quote ("...not generally secure") not in agreement with what
Shawn said ("not very secure")?

> deployment problem wrt NAT-like situations though.

Indeed, no security _harm_ results from using channel binding to network
addresses.

However, channel binding to network addresses adds little or no
security.  It can only add security when the network is physically
secure or IPsec (or equivalent, for non-IP networks) is in use, and then
only if a) IPsec protection is end-to-end, b) the IPsec policy ties
peers and IP addresses together tightly, and c) the IPsec policy does
not change adversely during the life of the connection.

Channel binding to network addresses could be seen as a proxy for
channel binding to IPsec, but only in very specific circumstances,
circumstances that applications cannot check for without having IPsec
APIs, and if they do then they might as well have access to IPsec
channel APIs that export channel bindings.  There are no APIs for
determining that the network path between two hosts is physically secure
either.

Given that channel binding to network addresses adds little or no
security, may lead to a sense of false security, is difficult to use in
any way that does add security, and will cause problems when NAT is in
the picture, channel binding to network addresses is best discouraged.

Nico
--