Subject: [anonsec] AD Review: Probably and Applicability Statement

From: wang.yushun at gmail.com (Yu-Shun Wang)
Date: Mon, 21 May 2007 00:22:55 -0700

Hi Sam,

Thanks for the reviews. Some comments inline.

Sam Hartman wrote:
> 
> 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?)

> 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.

> 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.

> 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.

> 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.)

> 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

---

From: hartmans-ietf at mit.edu (Sam Hartman)
Date: Mon, 21 May 2007 10:57:10 -0400

>>>>> "Yu-Shun" == Yu-Shun Wang <wang.yushun at gmail.com> writes:

    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.
    >> 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.

    >> 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.

---

From: wang.yushun at gmail.com (Yu-Shun Wang)
Date: Wed, 23 May 2007 14:27:18 -0700

>>>>>> "Yu-Shun" == Yu-Shun Wang <wang.yushun at gmail.com> writes:

<...>

>>> 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?
> 
> 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?

> 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.

>   (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.)

> * How do you support key rollover/what do you say about this

I thought that's part of IKE SA rekeying?

> 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. :-)

> 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

---

From: mcr at sandelman.ca (Michael Richardson)
Date: Thu, 24 May 2007 10:56:30 -0400

Sam Hartman wrote:
> 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?
> 

(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.

> 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).