Black_David at emc.com ()
2007-07-25 20:52:29 UTC
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
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
----------------------------------------------------
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
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 line5.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?
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
----------------------------------------------------