Re: [saag] new terminology ID posted

[Stephen Kent <[e-mail]>]

Tero,

Thanks for your comments. Responses inline below.


> Stephen Farrell writes:
>> a) "go for it, and here are my editorial comments," or,
> I would say "go for it"...
>
> and here is my comments to it:
> ----------------------------------------------------------------------
> In 3) in Section 1 there is reference to IKE but the RFC points to the
> TLS 1.0:
>
>         passive wiretapping.  IKE [RFC2246] has offered this capability,
>         	       		     	  ^^^^^^^
>         though it does not appear to be commonly used.)
>
> This should be RFC5996 (and this is why I like much better to use
> refences in style of [IKEv2] than [RFC5996]).
I've been working with two colleagues here at BBN to do the edits and 
some errors
have crept in via that interaction. We've fixed this reference to point 
to IKEv2.
At this stage I am loathe to change the reference style throughout the 
doc, but when
we near the end we can revisit that decision.
> --
>
> In section 2 we should refer to IKEv2 not IKE first, as RFC2409 is
> obsoleted by RFC5996:
>
>     Opportunistic encryption still calls for each party to identify the
>     other, using IKE [RFC2409] (equivalently, IKE v2 [RFC5996])
>     authentication mechanisms, so it is not an unauthenticated key
>     management approach.  ....
>
> i.e change "using IKE [RFC2409] (equivalently, IKE v2 [RFC5996])" to
> "using IKEv2 [RFC5996] (equivalently, IKEv1 [RFC2409])"
fixed.
>
> --
>
> In section 3 it says that TLS uses LoF or TOFU for the client
> authentication, but I do not think that is true:
>
> 		      	     	   TLS normally affords server
>     authentication (based on X.509 certificates and the so-called Web
>     PKI), and offers optional support for client authentication based on
>     a leap of faith (LoF) or trust on first use (TOFU) approach.  Because
>     SSH is most often employed in an enterprise context, reliance on
>     these initial authentication mechanisms represents a reasonable risk-
>     based design tradeoff.
another editing whoops that we have fixed.
> Both LoF and TOFU quite often do require user interface i.e user to be
> able to notified if the certificate changes or whether this is new
> connection. When doing TLS *CLIENT* authentication the server does not
> have user at all, so using LoF or TOFU there would be hard.
absolutely correct.
> I would say that in TLS the client authentication is commonly not done
> at all inside the TLS, but it is done after the connection to the
> server is done in a form of user name and password or similar
> non-cryptographic ways.
agreed.
> The next paragraph talks about SSH, but even in SSH it does not use
> LoF or TOFU on the *CLIENT* authentication. SSH commonly uses the
> method where the first connection to new server gives a warning saying
> this is new connection and user will accept the connection and the key
> returned from the other end on the first connection is stored to the
> database and checked for all later uses. If key is changed then user
> is given again a warning asking what to do (connect anyways, connect
> and change the key in database, or do not connect). All of this is
> done on the server authentication not client authentication.
yes. I have revised the text here to make clear that TOFU/LoF applies
to server, not client, auth.
> There is no CLIENT authentication in the SSH, there is USER
> authentication which usually will require server and client to share
> some kind of bilateral arrangement (store the password to the server
> side database, or store the user's public key to the authorized keys
> file on the server etc), and this user authentication is run after the
> server authentication has finished.
I have added some text to better describe SSH user auth. Let me
know if the text in the next rev suffices.
> As the next paragraph talks about the TLS, I assume the first
> paragraph was supposed to talk only about SSH, i.e. the first TLS was
> typo.
Actually, it was the other way around, but because text was mashed
together in the course of making revisions, the result was just a mess.
> BTW, I myself have categorized the different generic IETF security
> protocols as follows:
>
> +---------------+-----------------------+---------------------+
> |		| Bilateral		| Unilateral          |
> |		| agreement  		| or no		      |
> |		| between		| agreement	      |
> |		| peers			| between peers	      |
> +---------------+-----------------------+---------------------+
> | Above TCP	| SSH			| TLS		      |
> | i.e. usually	|			| 		      |
> | implementable	|			|		      |
> | in usermode	|			|		      |
> |    		|			|		      |
> | Asymmetric	|			|		      |
> | authentication|			|		      |
> +---------------+-----------------------+---------------------+
> | Below TCP	| IKE			| HIP		      |
> | i.e. usually	|			|		      |
> | do require	|			|		      |
> | kernel change	|			|		      |
> |    		|			|		      |
> | Symmetric	|			|		      |
> | authentication|			|		      |
> +---------------+-----------------------+---------------------+
Nice diagram. I'll have to see if we can make use of it, or a similar
version in the future.
> Of course TLS with client authentication will require bilateral
> agreement, and also if you use TLS with username + password
> authentication over HTTP or similar that will require bilateral
> agreement.
agreed, but when one uses a password with TLS it's not part of TLS
anymore, it's the app above TLS. I want to address intrinsic properties
of the protocols, as specified and as commonly used, in this doc.
> On the other hand Opportunistic Encryption in IPsec does not require
> bilater agreement, i.e it moves to the same box than HIP. I.e. the
> uses for the protocols are not that clear, but that gives at least in
> my understanding the basic idea where the protocol was designed for
> and/or what is the main use for it now.
agreed. do you think we need to include more text about this?
> The bilateral agreement makes it harder to get it used everywhere.
> Unilateral or no-agreement are much easier in that sense (usable
> everywhere). Whether the protocol can be implemented in the usermode
> (or inside application) that makes it much easier to get it deployed
> everywhere. Requiring access to parts below TCP stack usually requires
> kernel modification or at least special credentials which makes it
> much harder to deploy the protocol everywhere.
yes, bilateral, a priori agreement requirements are clearly an impediment to
deployment, and thus should be avoided when one is trying to maximize use
of encryption. (Gee, I guess I should find a place to say that :-) in 
the doc.)

Also, changes to kernel code are another impediment to deployment, at least
in terms of rate of uptake. (The recent comments about how many copies 
of XP are
still in use should be a lesson for us re OS-based changes.)
> Symmetric authentication is more suitable in peer to peer connection,
> compared to the asymmetric authentication where the protocol is more
> suitable for client (with user) and server uses.
I'll have to think about that. IPsec is p-t-p.
> --
>
> In section 4 you have reference to the RFC4306 (IKEv2), which should
> be replaced with RFC5996 (latest version of IKEv2).
fixed.
> Also there is text saying:
>
>     Finally, we avoid using the term "unauthenticated
>     encryption" because "authenticated encryption" is a well-defined term
>     in the crypto community.  Instead we use the term "authenticated
>     encrypted communication".
>
> Is this text correct? You say we avoid using therm "unauthenticatged
> encryption" but use "authenticated encrypted communication" instead? I
> would assume both of them should either say "unauthenticated" or
> "authenticated", i.e. change the text to say '... term "unauthenticated
> encrypted communication".'
fixed.

Thanks for all of the comments.

Steve