[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ESP Introduction

Notwithstanding the derogatory comments that prefixed his message, there
remain a few substantive issues:

> From: Stephen Kent <kent@bbn.com>
> >Technically, "data origin authentication" requires a long term key,
> >usually verified in the form of a signature.  It is a term normally
> >reserved for applications such as email.  ESP is defined for ephemeral
> >keys.  Again, "data origin authentication" is not provided by ESP.
>
> While it is true that a long term key often is involved as a basis for DOA,
> signatures are in no way needed, e.g., KDC-based systems like Kerberos
> provide DAO based on a long-term symmetric key, which is used to bootstrap
> to a TGT, etc.  The fact that a key used with ESP may be ephemeral is
> irrelevant to the question of whether DOA is provided.  The literature
> citations I provided earlier, as well as others, support this
> characterization
>
How, exactly, does your adding the terms "data origin" and
"connectionless" to our earlier agreed language (massaged by WG
discussion in 1995) help write a protocol implementation?

How, exactly, is "data origin" authentication provided when the same
SPI is given to 20 folks to traverse a firewall?

How, exactly, is my "usually" and "normally" different from your
"often" and "in no way needed"?  Are signatures never or rarely
involved?  What basis of evaluation are you using?

Keep in mind, I am not at all interested in ISO specification language.
If particular language is to be used here, writing a draft for us to
review (and change) should have been your highest priority.  You have
already refused.

Until then, I'll stick with "Applied Cryptography", which sits next to
the keyboard and is extremely useful to implementors; and "Handbook of
Applied Cryptography", which sits back in the library as it is much less
useful to implementors.

Also, your US DoD roots are showing.  I remind folks that you were
involved in Clipper/Fortezza/SkipJack review.

Historically speaking, in this WG, there was a strong sentiment against
using Clipper/SkipJack/Fortezza.  There was an undercurrent desire
rarely expressed in public that we didn't want any SPI to have "data
origin" authentication, because we didn't want the SPI to be a subpoena
relevant entity.  We spent a lot of effort to try to ensure that the
sender identity is hidden from outside parties.

There, I've admitted it in writing.  So, stop trying to put it back!


> terminology if the WG deems it appropriate.  Routers acting as firewalls
> are good candidates for IPSEC implementations, but then so are firewalls
> that are not acting as routers.

Let us be perfectly clear, there are two and only two entities that
apply to the Internet Protocol (the domain of this WG):
 1) hosts (ISOese "end systems")
 2) routers (ISOese "intermediate systems")

If it passes IP packets between two interfaces, it is a router.

At context levels above IP, such as transport, there are gateways.
Please ensure that the text conforms to this long-standing Internet
terminology.


> The term "transform" was retired when we moved from trivial base documents
> and a combinatorially expanding set of transform documents,

The term transform has been resurrected for lack of a better term, and
given a tighter definition.  I was long opposed to combinatorial
expansion, and am pleased that the WG has finally come around to earlier
thinking.  We have ciphers and authenticators.  Each "transforms" their
data.  The ESP document needs to reflect this.  I have submitted
complete and expressive language.  Use it.


> **** Most egregious is that it is missing critical information  ****
> **** from RFC-1827: the IP Next Header/Protocol number :-(.     ****
>
> Well, Bill, you got me there!  Somewhere along the way we dropped this
> important datam and you are the first person to point that out.  We'll
> certainly amend the text to specify the protocol values for Ah and ESP, in
> the respecvtive documents.
>
I suggest that, perhaps, the documents were so dense that very few took
the effort to read them....  It took me weeks.  These comments are not
being composed without considerable effort.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: