[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SIPP Security I-ds
Ran,
I've looked at the ESP and AP drafts you circulated. My first
question is why this needs to be distinct from the IPSP effort. It
seems to me that both are trying to define a simple (but possibly
extensible) network layer encapsulation protocol which might be used
with any IP style protocol (IPv4, IPng, etc.). In that vein, it seems
to me that this draft (or a subtle variant) would also serve well as a
candidate for progressing discussions in the IPSP context. The
following comments have, therefore, somewhat of a dual nature and I've
included the ipsec list.
Dave
ESP
Section 1.1. You describe here a model which states that ESP must
encapsulate a complete SIPP datagram (i.e. SIPP-ESP-SIPP-payload),
while in sectio 5, you describe how SIPP-ESP-payload may be
appropriate for end systems. I agree that the two cases are
both appropriate, but wanted to understand your intent regarding
when and how the two cases are selected.
Section 3.1/SAID In the multicast case, even if I have a separate SAID
and key for each originator, I cannot authenticate the sender. To
support multicast, each recipient must hold the key of each of the
originators. Assuming symmetric keys for ESP encryption, this means
that any member of the group can masquerade as any other member of
the group. Without dropping back to asymmetric techniques, you might
as well have a single group SAID.
Section 3.1/Pad I don't understand the placement. For a cryptographic
pad to work, it needs to be part of the ciphertext.
Section 3.2/Sequence Numbers The field is optional, so I won't complain
too loudly, but I strongly dislike sequence numbers in a connectionless
network layer protocol. I think the processing and related rules are
more likely to disrupt than enhance service. As part of an
overall architecture, I advocate pushing replay detection to the
transport protocol or application which is concerned rather than
placing the service in the network layer.
Section 3.2 In addition to the fields you list, and based on IPSP
drafts, have you considered a length field? Also, I believe that
a security label within the protocol is a useful option, especially
where you are tightly coupling access control decisions with the
SA. You also have not discussed an integrity check (see AP comment
below).
Section 5/Labels I think this discussion highlights some of the
reasons for including an optional label in ESP/IPSP. For certain
environments where the enclave is treated as a whole, the label
for security protocol processing may be different than that
contained in the encapsulated SIPP datagram.
AP
I don't believe this needs to be a separate payload/protocol
than the ESP. One of the features of IPSP is the inclusion of
an ICV. This can be a simple checksum, MAC, or signature
style of check and can accommodate the services you describe
for AP. Since the services used on a particular security
association are negotiated (or at least variable) a single
protocol/payload specification can support authentication only,
confidentiality only, or both. With recursive encapsulation I
can even decouple them. On the other hand, by forcing them to
be separate, I pay an overhead and performance penalty for the
common case where I want both services since you have omitted an
integrity check from ESP.