[anonsec] AD Review: Probably and Applicability Statement

[Sam Hartman]

Hi, folks. I've finished reviewing the Problem and Applicability
Statement draft.

I'd like to thank the authors for a lot of good work.


Several of the comments I made in my first review of the document
still haven't been fixed. Terms like flash crowd, DDOS, zombies are
not defined before they are used.


Section 5.3 claims that passwords over anonymous channels are
inappropriate. I don't think there is an ietf consensus behind this.
Replace
old:
Therefore, CBB must not be used with higher layer protocols
that may expose sensitive information during authentication exchange.

with new:
Therefore, CBB must not be used with higher layer protocols
that may expose sensitive information during authentication exchange where the exposure of this information presents an unacceptable security risk.


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?

If there is such a consensus then Section 5.7 should be removed and a
section added to the applicability statement saying that leap of
faith/credential caching is out of scope.

Section 6 rules mobility, nat and multihoming out of scope. Please
provide an argument that btns does not make issues associated with nat
and multihoming worse. IN particular think about address selection
for inner addresses with anonymous open services and show that this
problem is not worse in a BTNS universe.

If you can do that then you can attempt to rule NAT and
multihoming/mobility out of scope. I'll still call it out in the IETF
last call message and confirm that the community is willing to let you
rule this out of scope.

Sam Hartman
Security Area Director

[Yu-Shun Wang]

Hi Sam,

Thanks for the reviews. Some comments inline.

Post by Sam Hartman
Hi, folks. I've finished reviewing the Problem and Applicability
Statement draft.
I'd like to thank the authors for a lot of good work.
Several of the comments I made in my first review of the document
still haven't been fixed. Terms like flash crowd, DDOS, zombies are
not defined before they are used.

Unless someone can provide citations, I am going to replace
these terms as below:

s/flash crowd/unexpected surge of legitimate requests/
s/zombies/compromised systems/
s/DDoS/distributed denial of service/

(Seriously, do we still have to explain DDoS here? Or we
just need to spell it out?)

Post by Sam Hartman
Section 5.3 claims that passwords over anonymous channels are
inappropriate. I don't think there is an ietf consensus behind this.
Replace old: Therefore, CBB must not be used with higher layer
protocols that may expose sensitive information during authentication
exchange.
with new: Therefore, CBB must not be used with higher layer protocols
that may expose sensitive information during authentication exchange
where the exposure of this information presents an unacceptable
security risk.

Will do. Thanks for the text.

Post by Sam Hartman
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?

At our original draft draft, I left it as "?" (or TBD)
We can change it back to TBD.

The text (as I remembered) deliberately does NOT take a
position on the debate of what LoF is between the two
mechanisms: accepting the unauth ID vs. caching it (and
treating it differently next time). We just explained
what the two mechanisms are and stated the status of
our understanding. I am personally neutral to this.
It's the WG's call.

By the way, we (the authors) went through a lot of discussion
to keep the position neutral, stating the issues involved
and what will need to happen (at a very high level) to make
it work or secure. IIRC we didn't shut the door so to speak.

Post by Sam Hartman
If there is such a consensus then Section 5.7 should be removed and a
section added to the applicability statement saying that leap of
faith/credential caching is out of scope.

I'd appreciate if such text doesn't involve why it's out of
scope. Otherwise we'd be repeating the current 5.7 again.

Post by Sam Hartman
Section 6 rules mobility, nat and multihoming out of scope. Please
provide an argument that btns does not make issues associated with
nat and multihoming worse. IN particular think about address
selection for inner addresses with anonymous open services and show
that this problem is not worse in a BTNS universe.

I am no expert to all of those. Text suggestion?

(I thought those were not in the charter, didn't realize
we have to explain why they are not in the charter.)

Post by Sam Hartman
If you can do that then you can attempt to rule NAT and
multihoming/mobility out of scope. I'll still call it out in the
IETF last call message and confirm that the community is willing to
let you rule this out of scope.

Sure.

Thanks,

yushun

[Sam Hartman]

Yu-Shun> Hi Sam, Thanks for the reviews. Some comments inline.

Yu-Shun> Unless someone can provide citations, I am going to
Yu-Shun> replace these terms as below:

Yu-Shun> s/flash crowd/unexpected surge of legitimate requests/
Yu-Shun> s/zombies/compromised systems/ s/DDoS/distributed denial
Yu-Shun> of service/

Yu-Shun> (Seriously, do we still have to explain DDoS here? Or we
Yu-Shun> just need to spell it out?)

Spelling it out is sufficient.

Post by Sam Hartman
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?

Yu-Shun> At our original draft draft, I left it as "?" (or TBD) We
Yu-Shun> can change it back to TBD.

Yu-Shun> The text (as I remembered) deliberately does NOT take a
Yu-Shun> position on the debate of what LoF is between the two
Yu-Shun> mechanisms: accepting the unauth ID vs. caching it (and
Yu-Shun> treating it differently next time). We just explained
Yu-Shun> what the two mechanisms are and stated the status of our
Yu-Shun> understanding. I am personally neutral to this. It's the
Yu-Shun> WG's call.

Yu-Shun> By the way, we (the authors) went through a lot of
Yu-Shun> discussion to keep the position neutral, stating the
Yu-Shun> issues involved and what will need to happen (at a very
Yu-Shun> high level) to make it work or secure. IIRC we didn't
Yu-Shun> shut the door so to speak.

That's not how the section currently reads at all.
The last sentence tries to keep the door open but really does not interact well with the table where you say that caching cannot be done in BTNS.

The section also does not discuss the problems with unauthenticated credentials.
IT says what extra work is needed but not really why.
Extra work includes:

* A Mechanism for user acceptance before caching
* How do you know when you are talking to the same peer (mobility/address ownership issues)
* How do you support key rollover/what do you say about this

IMHO, you're not done with this section. If the authors don't have the experiense internally to complete this section then the WG needs to provide that.

Post by Sam Hartman
Section 6 rules mobility, nat and multihoming out of scope.
Please provide an argument that btns does not make issues
associated with nat and multihoming worse. IN particular think
about address selection for inner addresses with anonymous open
services and show that this problem is not worse in a BTNS
universe.

Yu-Shun> I am no expert to all of those. Text suggestion?

You need to get someone to do the engineering work first. I.E. I
think it may well be the case that BTNS creates problems in these
areas that need to be addressed. Someone in the WG actually needs to
work through these issues enough to figure out whether that's the
case. I simply provided requirements you'd need to meet if you want
to take the current direction.

Yu-Shun> (I thought those were not in the charter, didn't realize
Yu-Shun> we have to explain why they are not in the charter.)

As far as I can tell the charter does not speak to these issues one
way or the other. If you think it does please point out the text in
the charter that speaks to this issue so I can take a look at whether
I'm asking you to go beyond your charter.

Yu-Shun> Thanks,

Yu-Shun> yushun

Thanks again for excellent work.

[Yu-Shun Wang]

<...>

Post by Sam Hartman

Post by Sam Hartman
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?

Yu-Shun> At our original draft draft, I left it as "?" (or TBD) We
Yu-Shun> can change it back to TBD.
Yu-Shun> The text (as I remembered) deliberately does NOT take a
Yu-Shun> position on the debate of what LoF is between the two
Yu-Shun> mechanisms: accepting the unauth ID vs. caching it (and
Yu-Shun> treating it differently next time). We just explained
Yu-Shun> what the two mechanisms are and stated the status of our
Yu-Shun> understanding. I am personally neutral to this. It's the
Yu-Shun> WG's call.
Yu-Shun> By the way, we (the authors) went through a lot of
Yu-Shun> discussion to keep the position neutral, stating the
Yu-Shun> issues involved and what will need to happen (at a very
Yu-Shun> high level) to make it work or secure. IIRC we didn't
Yu-Shun> shut the door so to speak.
That's not how the section currently reads at all. The last sentence
tries to keep the door open but really does not interact well with
the table where you say that caching cannot be done in BTNS.

Sure. I'll change the table to TBD then. Ok with the WG?

Post by Sam Hartman
The section also does not discuss the problems with unauthenticated
credentials. IT says what extra work is needed but not really why.

Let me see if I understand your concerns: (correct me if I am wrong)

(1) the doc does not discuss the problems with unauth'ed credentials
(2) the doc does not explain why extra work is needed

My understanding is that SSH-style LoF does three things:
(a) ask users if they want to accept unknown credentials
(b) cache them if the users say "yes"
(c) accept the cached credentials in the future w/out prompts
This effectively "upgrades" the cached credentials to
a higher level of trust in SSH.

The position the authors agreed upon is that for SAB, you
should not do that, especially (c). The problem is "... the
credentials should not be cached because they remain
unauthenticated, ..." IMO that is the problem, or at least
the core of it. For CBB, it's less of a concern because you
will need to do higher level auth anyways, just like SSH
actually.

I am not sure what other problems or reasons you have in mind
other than "it's still unauthenticated, you probably should
not trust it." That, to me, is the reason and problem.

Things you listed below are additional work IF we want to
go that route. To me that belongs to another doc.

Post by Sam Hartman
* A Mechanism for user acceptance before caching
* How do you know when you are talking to the same peer
(mobility/address ownership issues)

These sound like the SSH stuff listed above (a)-(c) plus
the verification. The current text:

"
SSH-style credential caching for reuse with SAB can be added as a
future extension to BTNS-IPsec; such work would need to provide
warnings and checks on unauthenticated credentials in order to
establish a level of assurance of authentication compared to SSH's
"Leap of Faith."
"

While not in so much details, IMO provide a high level picture
of your list, no? (I can of course just change the text to
your list. But it's still not clear to me what else in the
rationale part I missed regarding the tasks.)

Post by Sam Hartman
* How do you support key rollover/what do you say about this

I thought that's part of IKE SA rekeying?

Post by Sam Hartman
IMHO, you're not done with this section. If the authors don't have
the experiense internally to complete this section then the WG needs
to provide that.

Again (to the wg), text suggestion is most welcome. :-)

Post by Sam Hartman

Post by Sam Hartman
Section 6 rules mobility, nat and multihoming out of scope.
Please provide an argument that btns does not make issues
associated with nat and multihoming worse. IN particular think
about address selection for inner addresses with anonymous open
services and show that this problem is not worse in a BTNS
universe.

Yu-Shun> I am no expert to all of those. Text suggestion?
You need to get someone to do the engineering work first. I.E. I
think it may well be the case that BTNS creates problems in these
areas that need to be addressed. Someone in the WG actually needs to
work through these issues enough to figure out whether that's the
case. I simply provided requirements you'd need to meet if you want
to take the current direction.

Fair enough. Other comments and texts from the WG?

(I am in the process of moving. So apologize in advance of
any delay on my part.)

Thanks,

yushun

[Michael Richardson]

Post by Sam Hartman
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?
If there is such a consensus then Section 5.7 should be removed and a
section added to the applicability statement saying that leap of
faith/credential caching is out of scope.

(re-reads 5.7)
I think that we wish to retain it.

btw, I think that s/SSH/implementations of the SecSH protocol/ there.

5.7 doesn't really tell me whether I'm allowed or encouraged to cache
credentials. Remember that a ssh client gets to interact with the user, while
the IPsec IKEv* usually does not. This is the point of the table, but perhaps
that point is lost.

Finally, the decision to cache the credentials for next time is something
a compliant implementations could do as a "local matter". Where it matters is
whether we have any mechanisms for invalidating the cache, or indicating that
records should be purged. SSH started without that. It now has provisions to
do that via a DNSSEC authenticated SSHFP record.

Post by Sam Hartman
and multihoming worse. IN particular think about address selection
for inner addresses with anonymous open services and show that this
problem is not worse in a BTNS universe.

Yes, I asked this question several times in person and on the list,
and the consensus was that BTNS would not function with IPsec NAT-traversal,
because we didn't know what to propose for the inside (CHILD_SA).