Subject: [MSEC] Data Security Architecture document

From: Ran Canetti <[email-masked]>
Date: Tue, 22 Apr 2003 16:19:45 -0400

Folks,

As we know, the MSEC charter calls for a document describing 
the architecture of the MSEC data security transforms. There is a proposal
to base much of this draft on the current mesp draft 
(draft-ietf-msec-mesp-01.txt), and to discontinue the mesp draft.
The proposed structure of the data security transforms 
architecture (d-star) darft is roughly as follows:

1. A general part describing the required functionalities of data 
security transforms (confidentiality, source authentication, group
authentication).

2. A part summarizing the information included in the data SA generated by the 
key management protocols.

3. A part describing how to do data protection in the IP layer. This will be
based mostly on the current MESP draft (and will be compatible with IPSEC's
ESP).

A question here: Does anyone see a need to discuss also a "Multicast AH"
(or MAH), analogously to MESP?

4. A part describing how to do data protection in the application layer,
based on SRTP. (This is a new section that did not appear before.) 

What do people say?
If there are no objections then the hope is that a first draft will be out
within a month or so.

Ran

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: George Gross <[email-masked]>
Date: Tue, 22 Apr 2003 15:34:34 -0400 (EDT)

Hi Ran,

On Tue, 22 Apr 2003, Ran Canetti wrote:
<snip>

> (or MAH), analogously to MESP?
hmmm... yes, I can think of an application domain that might have a need
for this capability.

There are two scenarios that come to mind:

1) the local legal jurisdiction does not allow encryption or it requires
source authentication when using encryption, and/or at the same time the
protection of the IP header integrity is a requirement,

2) you are transporting a payload that does not contain secrets (i.e. no
encryption needed) but you want to assure the IP header is source
authenticated.... perhaps IPv6 SEND could fit this profile? or a VoIP
teleconference that requires non-repudiation evidence.

br,
	George

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 22 Apr 2003 17:38:05 -0400

Wouldn't ESP with null encryption work in those cases?

That said, how about preserving header integrity protection offered by 
AH in some form?

cheers,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 22 Apr 2003 17:43:49 -0400

I missed the non-repudiation bit in my reply.  We discussed it at the 
Atlanta meeting and decided (as with IPsec transforms) against providing 
non-repudiation at network layer.

regards,
Lakshminath

---

From: George Gross <[email-masked]>
Date: Tue, 22 Apr 2003 17:05:29 -0400 (EDT)

Hi Lakshminath,

	well, working groups achieve their rough consensus on the mailing
list ;o) since I was not at Atlanta, what was the basis of the decision on
the "against providing non-repudiation at network layer..."?

	From what I can tell, we agree that having IP header integrity
protection is a requirement, so don't we get source authentication and
non-repudiation for essentially free?

br,
	George

---

From: Mark Baugher <[email-masked]>
Date: Tue, 22 Apr 2003 17:02:51 -0700

At 05:38 PM 4/22/2003 -0400, Lakshminath Dondeti wrote:
>That said, how about preserving header integrity protection offered by AH 
>in some form?

I think we need AH for this purpose

Mark

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 23 Apr 2003 14:55:58 -0400

Please see inline:

> the "against providing non-repudiation at network layer..."?

Yes, you are right about the procedure for consensus.  But there was 
some discussion on the topic late last year.  I am not sure whether that 
qualifies as consensus.

http://www.pairlist.net/pipermail/msec/2002-November/000584.html

The question is whether always-on non-repudiation without regard to 
various applications' requirements is a good feature.  For many, 
including me, the answer is no.  For example, it may be required for 
Business related VoIP conferences, but may be undesirable for personal 
calls.

The new MESP draft authenticates encrypted text and therefore does not 
support non-repudiation as a feature (not even as an option, as I recall 
;-)).  Is AMESP still alive?

regards,
Lakshminath