[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ESP Introduction
Bill,
You continued, though belated, inputs to the document editing process are
appreciated. However, gratituous assults on my competence with respect to
network security are unsubstantiated, as well as unwarranted.
>Unfortunately, Kent's lack of understanding lead to a significant
>problem with the ESP terminology used throughout.
>
>For example, in the introduction, s/he writes:
>
> ESP is used to provide confidentiality, data origin authentication,
> connectionless integrity, an anti-replay service (a form of partial
> sequence integrity), and limited traffic flow confidentiality. The
>
>Since the SPI is destination based, and does not imply a particular
>sender (especially in a multicast environment) or Security Association,
>"data origin authentication" is not provided by ESP.
>
>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.
Data origin authentication is an appropriate way to describe the service
offered by AH or ESP, even in the multicast context. The difference is the
granularity of the authentication provided. If an SA is bound to a
specific IP address, protocol, and port, (or to a user ID on a host), then
the granularity of authentication is rather fine grained. If traffic from
multiple sources in a corporate network environment is muxed into a single
SA then the authentication granularity is coarse, but authentication is
still being provided.
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
>As I've noted before on this list, Internet Protocols do not provide
>"connectionless" anything. Perhaps Kent meant to use the technical term
>"datagram". Most of us would simply say "data integrity".
>
>In any case, the integrity can either be provided by the cipher or the
>independent authenticator algorithms, and should not be listed as a
>special "feature" of ESP. We argued this long ago. I remember a very
>critical Rogaway draft. Indeed, after defining it as a separate ESP
>feature, Kent consolidates it under "authentication" in the remainder of
>the draft.
Although integrity is technically a separate service from authentication,
one is rarely provided absent the other. If one doesn't know the origin of
a packet, but claims that it is integrity protected, this is a rather odd
security guarantee in most circumstances. Similarly, to say that a packet
is definately from some source, but to not know if it has been modified en
route is not very useful. Thus we often use the terms integrity and
authenticity in combination in describing the features offered by a given
mechanism. Technically, the mechanisms used in AH or ESP provide
integrity, and it is the management of the keys used in the computation
that afford authenticity, at some granularity. An encryption algorithm,
per se, does not provide a basis for determining the integrity (or
authenticity) of received data. Only the inclusion of predictable,
redundant information in the data allows for such determination. If one
wants to be quite precise, an encryption process may provide support for a
separate mechanism that determines the integrity of the received data.
>The term "gateway" is incorrect (obsolete term for "router") or limiting
>(as in application gateway).
I retained the term "security gateway" in deference to Ran's use of the
term in the RFCs and the arch I-Ds, but I'm quite willing to adopt other
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. Inline IPSEC devices, analogous tothe
network security products produced by Semaphore and Motorola for several
years, are not routers, nor are they firewalls with IPSEC-based VPN
features added in. That's why I thought that Ran's use of the term
"secruity gateway," when defined for this context, was an appropriately
neutral term.
>Inexplicably, the _useful_ RFC-1827 "Overview" is entirely missing. The
>RFC-1827 "Requirements Terminology" is missing, and should be RFC-2116.The
>>RFC-1827 "Key Management" information is missing, although some of
>that belonged in the Architecture. The RFC-1827 "transform" language is
>missing.
The terminology discussion was removed from AH and ESP some time ago, and
no complaints were received. A suitable glossary will appear as an
appendix in the architecture document, as will the key management
discussion.
The term "transform" was retired when we moved from trivial base documents
and a combinatorially expanding set of transform documents, to more
comprehensive base documents accompanied by documents that describe how to
employ an individual algorithm in the context of AH or ESP. The allowed
combinations of algorithms are defined elsewhere, e.g., in terms of the
ISAKMP negitiated attributes.
**** 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.
As for the remainder of your proposed text, we'll be working with the
co-chairs to resolve any outstanding issues in producing the next rev of
the documents, and I'll defer to their judgement.
Steve
References: