Subject: [anonsec] WG-LC: draft-ietf-btns-prob-and-applic-04

From: lha at kth.se (Love Hörnquist Åstrand)
Date: Tue, 5 Dec 2006 12:15:30 +0100

20 nov 2006 kl. 17.12 skrev Love H?rnquist ?strand:

> To verify the consensus of the wg and catch the the last errors before
> sending of the document to IESG I'm issuing a WG last call of
>
>                      Problem and Applicability Statement
>                    for Better Than Nothing Security (BTNS)
>
> http://www.ietf.org/internet-drafts/draft-ietf-btns-prob-and-
> applic-04.txt

I've so far not seen one comment on the document, neither positive  
nor negative.

Love

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Sun, 3 Dec 2006 22:30:59 -0600

I think this document is mostly quite fine and almost ready.

Besides some minor editing I think that some text on authentication
assymetry in CBB could be removed.

Comments below.

> Abstract
> 
>    The Internet network security protocol suite, IPsec, consisting of
>    IKE, ESP, and AH, currently requires authentication via IKE of
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Does it?

>    network layer entities to bootstrap security. This authentication can
>    be based on mechanisms such as pre-shared symmetric keys,
>    certificates and associated asymmetric keys, or the use of Kerberos.

>    The need for authentication information and its associated identities
>    between network layer entities can be a significant obstacle to
>    deploying network security.  This document explains the rationale for
>    extending the Internet network security suite to enable use of IPsec
>    security mechanisms without full IKE authentication.  These
                                 ^^^^^^^^^^^^^^^^^^^^^^^

Can we find a better way to say this?

"without actually authenticating IKE peers"?

>    extensions are intended to protect communication "better than
						      ^
						      with
>    nothing" (BTNS) on their own (Stand Alone BTNS, or SAB), and may be
            ^
	     security
>    useful in providing network layer security that can be authenticated
>    by higher layers in the protocol stack, called Channel Bound BTNS
>    (CBB). This document also explains situations in which use of SAB and
>    CBB extensions are appropriate and can achieve their intended
>    benefit.

Also, s/on their own//.

>    Consider the case of transport protocols. Increases in network
>    performance and the use of long-lived connections have resulted in
>    increased vulnerability of connection-oriented transport protocols to
>    attacks. Such attacks can be resisted to some extent within the
>    transport layer by performing additional validity checks, requiring
>    additional mechanisms added to each transport protocol. More direct
     ^                     ^                                      ^^^^^^
     that                  be

s/direct/comprehensive/

>    security can be provided, either at the transport or network layer.
>    This security currently requires a predetermined way to authenticate

s/This security/Obtaining comprehensive security/

>    the endpoints with a pre-shared secret, a public key infrastructure
>    (PKI) with shared trusted anchors, or an external key coordination
                                           ^^^^^^^^^^^
s/an external/other/
>    system such as Kerberos. In all cases, secure communication can be
>    established only after endpoints mutually assert authenticated

s/assert authenticated/authenticate each other's/

>    identities as specified in their access control policies.
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
		and pass their access control policies

>    There is weaker notion of identity, one which is bootstrapped from
>    the session association itself. The identity doesn't mean "Bill
>    Smith" or "owner of shared secret X2YQ", but means something more
>    like "the entity with whom I have been communicating on connection
>    #23". Such identity is not invariant across associations, but because
>    it is invariant within an association it can still be used to provide
>    protection for that association.

 - I would add that it is possible, in some schemes (specifically the
   scheme in draft-btns-core), to refer to such an identity by a
   repeatable, non-spoofable handle.  In draft-btns-core this would be a
   public key, and it is non-spoofable because it is bound into the
   "connection" by IKE.

   This is useful because it allows one to ask "is my peer on connection
   #32 the same as I had on connection #23 three days ago?"

   I believe this is mentioned later in the I-D, but it could stand
   being mentioned here where the topic of identity is broached.

- Section 2.2 mentions the need, in CBB, for defining IPsec channels,
  but section 2.1 does not mention the need, in SAB, for either defining
  IPsec channels or LoF binding of BTNS peers to their addresses.  A
  minor inconsistentcy since the topic is handled subsequently.

 - Section 2.2, s/where similar relates to/where similarity relates to/.

 - Section 2.4,

>    BTNS is not intended to protect the key exchange itself, so this
>    presents an opportunity for a man-in-the-middle attack or a well-
>    timed attack from other sources. Stand-alone BTNS is further not
>    intended to protect the endpoint from nodes masquerading as
>    legitimate clients but rather to raise the level of effort of an
>    attack to that of emulating a client. BTNS together with
>    authentication from higher layers in the stack can protect from such
>    masquerading, depending on how the authentication is coupled with the
>    BTNS associations, and at a later point in the protocol exchange.

 - Note that in CBB the key exchange is protected a posteriori, thus
   _detecting_ MITMs.  This is quite similar to what happens in IKEv2.

 - Section 3.1: I would prefer most references to authentication
   a/symmetry in the application layer, in the CBB cases, be removed.

   Such as in the table that follows the first paragraph and the
   second part of bullet item 5 in the list that follows:

>    5. Asymmetric CBB (A-CBB): one side lacks network layer
>       authentication information and possesses authentication at a
>       higher layer in the protocol stack; there are two variants,
                                          ^
					  stop here and delete the
					  remainder.
>       Asymmetric IKE CBB(AI-CBB) where the other side possesses
>       conventional IKE-supported authentication, and asymmetric stand-
>       alone CBB (AS-CBB), where the other side lacks network layer
>       authentication information and lacks authentication at higher
>       layers

 - Section 3.1.3, remove this paragraph:

>    S-CCB could utilize application layer authentication, including
       ^^^
       CBB
>    challenge/response PINs, such as used by S/Key in software or copy
>    protection dongles, or login passwords. 

   I'm not sure where this came from, but it's neither quite right nor
   does it belong in this document.

 - Section 3.1.4.  I'm rather confused by this one and I think that by
   and larger we can completely get rid of the distinction between S-CBB
   and A-CBB.

   What the application does for authentication and whether that is
   symmetric or not is really none of BTNS' business.  We're trying to
   enable channel binding to BTNS -- that is, we're trying to say that
   BTNS is applicable to channel binding applications.

   Beyond that this I-D is simply not the right place to discuss the
   particulars of what happens at the application layer beyond saying
   that authentication at the app layer is to be bound to a BTNS
   channel.

   Nor is this I-D the right place to discuss the applicability of
   channel binding generally.

   So I think this section should be removed and the distinction of
   S-CBB vs. A-CBB should be removed as well.

 - Section 3.4:

>                  SAB                         CBB
>      -------------------------------------------------------------
>      Uses     Open services               Password/PIN services
>               Peer-to-peer
>               Zero-config. infrastructure

   Where did "Password/PIN services" come from?  What does that mean?

Nico
--

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 05 Dec 2006 20:04:50 -0800

I like it, but I'm biased ;-)

Can others please post?

Joe

Love H?rnquist ?strand wrote:
> _______________________________________________

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/anonsec/attachments/20061205/32266cab/signature.bin

---

From: julien.IETF at laposte.net (Julien Laganier)
Date: Wed, 6 Dec 2006 18:05:04 +0100

On Tuesday 05 December 2006 12:15, Love H?rnquist 
?strand wrote:
> > To verify the consensus of the wg and catch the
> > the last errors before sending of the document to
> > IESG I'm issuing a WG last call of
> >
> >                      Problem and Applicability
> > Statement for Better Than Nothing Security (BTNS)
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-btn
> >s-prob-and- applic-04.txt
>
> I've so far not seen one comment on the document,
> neither positive nor negative.

I finally managed to read the document, and I thought 
it well written and ready to be sent to IESG.

--julien

---

From: miika at iki.fi (Miika Komu)
Date: Fri, 8 Dec 2006 12:41:08 +0200 (EET)

> it well written and ready to be sent to IESG.

Agree. Some editorial nits below.

I had some troubles in understanding initially the loosely defined term 
"authentication" in the context of the draft but I think it is now more 
clear. Particularly, the term "PKI" is mentioned quite late in the draft, 
which is IMHO connected to the authentication term and to the motivation 
of the whole draft.

HIP is mentioned in section 2.2.1 briefly. Perhaps you could also mention 
that HIP has implicit channel binding mechanisms and reference RFC4423, 
HIP base draft or draft-ietf-hip-applications-00. In addition, the claim 
"such modifications are, at best, temporary patches to the ubiquitous 
vulnerability to spoofing attacks" requires some further explanation at 
least in the context of HIP.

-- 
Miika Komu                                       http://www.iki.fi/miika/

---

From: yushunwa at ISI.EDU (Yu-Shun Wang)
Date: Thu, 14 Dec 2006 11:48:29 -0800

> assymetry in CBB could be removed.

Thanks, Nico. I looked over the comments, but half way through,
I realized these are for the -01 version. It has changed a lot
since then :-). Most of the comments don't apply anymore or are
referring to the wrong section numbers. Could you take a look at
-04 and see if any of these problems still exists?

Thanks,

yushun

>>    IKE, ESP, and AH, currently requires authentication via IKE of

Hmm, that doesn't include the non-IKE cases with pre-shared secrets.
I'll remove IKE from that sentence:

"The Internet network security protocol suite, IPsec, consisting of
  IKE, ESP, and AH, currently requires authentication of network layer
  entities to bootstrap security. (...) "

Preshared secrets are covered in the next sentence.

>>    security mechanisms without full IKE authentication.  These

I think we can just say "without authentication." Is that
ok?

>>    CBB extensions are appropriate and can achieve their intended

I think these comments are for -01. It has changed since then. :-)

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Thu, 14 Dec 2006 14:26:17 -0600

> -04 and see if any of these problems still exists?

Oh crap.

---

From: yushunwa at ISI.EDU (Yu-Shun Wang)
Date: Thu, 14 Dec 2006 12:26:03 -0800

Hi, Miika,

Thanks for the comments. Some answers inline...

> clear. Particularly, the term "PKI" is mentioned quite late in the 
> draft, which is IMHO connected to the authentication term and to the 
> motivation of the whole draft.

Yes, these terms are used in the context of IPsec, which
I hope should be quite clear from the intro. But please
let me know if any of the specific usage in the text is
confusing.

As for PKI, I think this is the relevant text (bottom of page 2):

"                                                          Furthermore,
    authenticated credentials such as certificates signed by
    certification authorities (CA) can be cumbersome and expensive to
    obtain.
"

I hope we can get away with it without explaining what PKI is
and the problems with PKI. But also feel free to comment and
suggest text. :-)

> HIP is mentioned in section 2.2.1 briefly. Perhaps you could also 
> mention that HIP has implicit channel binding mechanisms and reference 
> RFC4423, HIP base draft or draft-ietf-hip-applications-00. In addition, 
> the claim "such modifications are, at best, temporary patches to the 
> ubiquitous vulnerability to spoofing attacks" requires some further 
> explanation at least in the context of HIP.

Agreed with HIP and channel binding part. But IMHO, these are
more subtle (you said "implicit" :-)) points that probably
should be covered in the CB doc for more details and comparison.

Also noted the second point on "temporary patches" re. HIP:

s/Such modifications/The TCP-specific modifications/

Would this work?

Thanks,

yushun