[anonsec] AD Review: Probably and Applicability Statement

[wang.yushun at gmail.com (Yu-Shun Wang)]

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

<...>

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

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

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

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

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