Subject: [anonsec] Finishing off the Problem and Applicability Statement draft

From: Black_David at emc.com ([email-masked])
Date: Wed, 25 Jul 2007 16:52:29 -0400

As discussed in this afternoon's btns meeting, Sam's AD review
of draft-ietf-btns-prob-and-applic-05.txt turned up a couple of
areas that need serious attention:
	1) Leap of Faith discussion (Section 5.7)
	2) NAT Traversal, mobility and multihoming issues
		(Sections 6.1 and 6.2)
The purpose of this message is to explain what the authors
propose to do about these areas, so that the WG chairs can
determine the rough consensus of the WG on what should be done.

Taking the areas in reverse order, the current sections 6.1 and
6.2 of the draft essentially say that NAT, mobility and multihoming
issues are out of scope.  Whether they are out of scope is a longer
discussion, but the approach agreed to in this afternoon's btns
meeting is to remove Sections 6.1 and 6.2 from the problem and
applicability statement draft, and deal with whether the issues
are in scope and what to do about them if they are in the context
of the WG's other drafts.

The Leap of Faith concerns are somewhat more involved.  Sam's
original review comments were:

>> I wonder if the working group has adequately reviewed section
>> 5.7.  In particular do we actually have a strong consensus that
>> caching of BTNS credentials is inappropriate?  We certainly
>> have a lot of issues to work through before we can recommend
>> this caching. But if there is no caching how is that leap of
>> faith at all?

The first problem is that the "Yes" and "No" in the last line
of the Section 5.7 table don't capture what's really going on;
it's not that BTNS credentials can't be cached, but rather
that there is no security advantage to doing so.

Here's the proposed change to correct that.

OLD:
      -------------------------------+---------+---------+ 
       Cache unauthenticated         |   Yes   |   No    | 
       credential for future refs    |         |         | 
      -------------------------------+---------+---------+ 
    
   SSH requires proper warnings and options in the applications to 
   reject unauthenticated credentials, while BTNS will accept those 
   automatically if they match the corresponding policy entries.
   Once SSH accepts a credential for the first time, it should be
   cached, and can be reused automatically without further warnings.

NEW:
      -------------------------------+---------+---------+ 
       Cache unauthenticated         |Required | Allowed | 
       credential for future refs    |         |         | 
      -------------------------------+---------+---------+ 
    
   SSH requires proper warnings and options in the applications to 
   reject unauthenticated credentials, while BTNS will accept those 
   automatically if they match the corresponding policy entries. Once 
   SSH accepts a credential for the first time, it should be cached,
   and can be reused automatically without further warnings.  BTNS
   credentials can be cached for future use, but there is no security
   advantage to doing so, as a new unauthenticated credential that is
   allowed by the policy entries will be automatically accepted, and
   BTNS-IPsec does not require IPsec to reuse credentials in a manner
   similar to SSH.  When IPsec does reuse unauthenticated credentials,
   there may be implementation advantages to caching them in BTNS-IPsec.

The next problem is that the last paragraph in the section speculates
about extending BTNS to duplicate SSH's functionality.  It needs to
be clearer that it is speculating about this, and acknowledge Sam's
point that if one wants SSH-like functionality, one runs into issues.

OLD:
   On the other hand, there are two key issues with BTNS-IPsec: whether 
   to cache credentials and if so, how to treat cached credentials. The 
   main reason to cache a credential is to treat it differently the next

   time it appears. For SAB without Channel Binding, the credentials 
   should not be cached because they remain unauthenticated, and BTNS-
   IPsec does not require IPsec to reuse credentials in a manner similar

   to SSH. For CBB, credential caching and verification are usually done

   at the higher layer protocols or applications, as well be discussed 
   in the next section. Caching credentials at the BTNS-IPsec is not as 
   important because the channel binding will bind whatever credentials 
   are presented (new or cached) to the higher layer protocol identity. 

NEW:
   SSH-style credential caching for reuse with SAB could be addressed
   by future extension(s) to BTNS-IPsec; such extension(s) would need
   to provide warnings about and a mechanism for user acceptance of
   unauthenticated credentials in order to establish a level of
   assurance of authentication comparable to SSH's "Leap of Faith",
   and would also need to deal with issues caused by the absence of
   identities in BTNS-IPsec.  At best a cached BTNS-IPsec credential
   reauthenticates the network-layer source of traffic when the
   credential is reused - in contrast, SSH credential reuse
   reauthenticates an identity.  Network layer re-authentication is
   further complicated by the ability of NATs to cause multiple
   independent network layer sources of traffic to appear to be one
   source (potentially requiring acceptance and caching of multiple
   BTNS-IPsec credentials), the ability of multihoming to cause one
   network layer source of traffic to appear to be multiple sources
   (potentially triggering unexpected warnings and requiring a user
   to re-accept the same BTNS-IPsec credential), and interactions
   with both mobility and address ownership changes (potentially
   requiring controlled BTNS-IPsec credential reassignment and
   invalidation).  These issues are left to be addressed by possible
   future work on addition of "Leap of Faith" functionality to
BTNS-IPsec.

   In contrast, for CBB, credential caching and
   verification are usually done at the higher layer protocols or
   applications, as will be discussed  in the next section. Caching
   credentials for CBB at the BTNS-IPsec level is not as important
   because the channel binding will bind whatever credentials are
   presented (new or cached) to the higher layer protocol identity.

Sam has reviewed these proposed changes and pronounced them
acceptable.  The authors propose to produce a -06 version of the draft
with these changes (plus some other minor edits) that Sam would then
take forward for IESG approval.

Thanks,
--David (for the draft authors)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: mcr at sandelman.ca (Michael Richardson)
Date: Wed, 25 Jul 2007 16:55:25 -0500

> issues are out of scope.  Whether they are out of scope is a longer

I am going to deal with each one seperately. This email is about NAT.

Q: If you remove the statement that they are out of scope, does this force
    us to deal with these issues now?

I would prefer not to deal with the issue of NAT-traversal until after
we have some running, interoperable code that does connection-latching.

I think that that connection-latching + transport mode solves some NAT 
traversal issues. The remaining concerns are that we have to be very clear 
about what kind of phase 1 IDs that we use --- on that we can get rough 
consensus after we have running code.

As far as I understand process, deciding to make NAT in scope and the deal 
with it in later documents requires adding milestone items to our charter.
I believe that it is therefore the same as excluding NAT from scope and then 
rechartering later on?

---

From: mcr at sandelman.ca (Michael Richardson)
Date: Thu, 26 Jul 2007 01:18:38 -0500

> issues are out of scope.  Whether they are out of scope is a longer

I believe that we should make mobility out of scope.
Actually, I am uncertain I know what it means to have mobility and BTNS.

Someone could comtemplate mixing MOBIKE and BTNS. I don't initially see
a reason why this can't be done at the protocol level.
The issue is that you can't construct a sane/safe security policy.
The major concern is that I think that BTNS will mostly be used for 
host/32<->host/32 connections, or in transport mode. I.e. BTNS will be 
constrained to permit some remote host to assert it's own IP.

MOBIKE, however, deals with someip/32===changingip/32...host connections,
and deals with how to change "changingip". I don't see how you can mix these
things.  If you write a security policy that says that anyone out there can 
assert any IP... well, it's not much of a policy.

The only other kind of mobility that I can see being mixed in with BTNS
is stuff described in the IFARE stuff. Let's leave that out of scope for
BTNS as well.

I don't think we can make mobility in scope.

---

From: mcr at sandelman.ca (Michael Richardson)
Date: Thu, 26 Jul 2007 01:37:40 -0500

> of the WG's other drafts.

What could it mean for BTNS to be multihomed?

Let's assume that we have a ULP that deals well with being multihomed... 
SCTP, and it wants to use channel bindings to secure all of the routes.

A security concern might be that something like this might happen:

      +-------+ b2
      |   B   |---\
      +-------+    \ 2
       b1 |         \
          |        +-----+
          | 1      |  M  |
        a1|        +-----+
       +------+     /
       |  A   |----/ 3
       +------+ a2

Let's say we start the connection on link 1, using SCTP.
They do IPsec, and with a channel binding, bind link 1 (a1...b1)
SCTP exchanges addresses a2/b2, and at some point decides to failover to that 
link. Traffic across that link causes a new IPsec connection, but it is 
intersepted by M. As the application had used channel binding to offload the 
privacy and integrity protection to IPsec, the link through M can now be 
intercepted.

Either the application must become aware that a new channel binding is 
necessary, or the IPsec connection for a2...b2 must be related to the one for 
   a1..b1.

What this really means is that connection latching must in fact latch the
identities used in a1...b1 to identities to be used for a2...b2. This is 
really no different from the case where a1...b1 must be rekeyed. The new SA 
must use the same identities as the old one.

I don't think that the connection latching document addresses this issue
directly, but I think that it could spell out this case, and a connection 
latching capable SCTP stack would be able to do the right thing.

So, I don't have a problem keeping this in scope.

---

From: mcr at sandelman.ca (Michael Richardson)
Date: Thu, 26 Jul 2007 02:01:40 -0500

wrong subject. sorry.

Michael Richardson wrote:
> _______________________________________________
>