[anonsec] Finishing off the Problem and Applicability Statement draft

[Black_David at emc.com ([e-mail])]

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
[phone]             FAX: [phone]
black_david at emc.com        Mobile: [phone]
----------------------------------------------------