Subject: [MSEC] MESP: The order of security primitives and some more questions...

From: Euchner Martin ICN M SR 3 <[email-masked]>
Date: Mon, 4 Nov 2002 16:22:25 +0100

Regarding the order of MESP security primitives 

Section 4.1 in paragraphs 1 and 5 state that
1) GS-then-GA = ENC, EXT	for both IPSEC ESP and MESP.

Section 4 implicitly says that
2) SrA-then-GA = INT, EXT

addressing the principles
that the expensive operation (GS, SrA) comes first and then the less
expensive one (GA)
and first encrypt then authenticate.

Now these two partial orders alone do not yet define the order of GS, SrA
and GA security primitives when applied in composition, yet one may be
tempted to deduce and assume the following order would be correct:
3) GS-SrA-then-GA = ENC, INT, EXT

However, section 5 last paragraph comes to a different order, namely
4) SrA-then-GS-then-GA = INT, ENC, EXT

I agree this arrangement would make sense, when the SrA operation is
significantly more expensive than GS such as when using digital signature
for INT.

However, as TELSA shows, INT operation may be cheap and would not be
significantly more expensive than EXT operation for GA. Thus, 4) would not
be optimal in any case and 3) would be better.

From a security perspective, 4) allows to protect (encrypt) the Internal
Authentication Parameters, giving an external attacker less information. I'm
not convinced if this is worthwhile, since for internal attackers, the
Internal Authentication Parameters are available anyway.

In 3), the Internal Authentication Parameters would of course not be
encrypted, since INT occurs after GS.

I believe that some more considerations on these ordering aspects should be
given (e.g. in the security considerations section, or in section 4).

Some other comments:
* Why does MESP not support AH (e.g. MAH)? Is there any reason?
* Table 5.1-1 lists TESLA as an external transform. However, the TELSA
drafts raise the impression, that TELSA actually be an internal mechanism
for source authentication. This appears confusing.

With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 62366
| ICN M SR 3                     mailto:[email-masked]
|                                mailto:[email-masked]
| Hofmannstr. 51                 Intranet:
http://intranet.icn.siemens.de/marketing/cs27/topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------

 -----Original Message-----
From: 	Mark Baugher [mailto:[email-masked]] 
Sent:	Tuesday, October 29, 2002 9:35 PM
To:	[email-masked]
Subject:	[MSEC] Re: I-D ACTION:draft-ietf-msec-mesp-00.txt

Folks,
   We updated this draft to fix an error and also a diagram, which was very 
confusing.  So, the I-D you should work from is at
http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-msec-mesp-00.txt

thanks, Mark
At 06:19 AM 10/29/2002 -0500, [email-masked] wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Multicast Security Working Group of the
IETF.
>
>         Title           : MESP: Multicast Encapsulating Security Payload
>         Author(s)       : M. Baugher, R. Canetti et al.
>         Filename        : draft-ietf-msec-mesp-00.txt
>         Pages           : 16
>         Date            : 2002-10-28
>
>Multicast ESP (MESP) is a security protocol for IP multicast data.
>MESP extends the IPsec Encapsulating Security Payload (ESP) protocol
>for multicast operation and supports source message authentication
>for multicast packets. MESP offers three improvements to IPsec ESP
>for multicast operation.  First, it allows a mix of group-secrecy,
>group-authentication, and source-authentication transforms to be
>applied to an MESP packet. Second, it extends ESP to authenticate
>messages sent by a member of the group using a digital signature or
>hybrid MAC and signature transform. And third, MESP identifies a
>security association (SA) using the IP address of the source in
>addition to the destination address and SPI.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-msec-mesp-00.txt
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the
username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-ietf-msec-mesp-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-ietf-msec-mesp-00.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail
readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>Content-Type: text/plain
>Content-ID:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-msec-mesp-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-msec-mesp-00.txt>

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

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

---

From: Ran Canetti <[email-masked]>
Date: Wed, 6 Nov 2002 22:55:38 -0500

> From [email-masked] Mon Nov  4 11:20:54 2002
> 
> Why not make the SrA always an INT?  Thus we will have SrA, GC followed 
> by GA, which makes it easy to understand, analyze and implement. 
> Besides, SrA, even if it is TESLA is more expensive than GA anyway.
> 
> Or perhaps, GC, SrA, GA is better considering delayed and probabilistic 
> authentication by some source authentication schemes.  This limits the 
> DoS attacks to consuming just buffer space; why decrypt until we know 
> that the packets are legitimate.  We lose non-repudiation (not provided 
> by TESLA, but the hash chaining schemes support it)  in this case, however.
> 
> The different options bother me, I am hoping we can avoid that.
> 
> cheers,
> Lakshminath
> 

Lakshminath,

There are a couple good reasons to do TESLA on the ciphertext rather than
on the plaintext:
1. On the receiving end, it is best to do the TESLA processing as 
early as possible from the moment the packet is received, to minimize 
the delay in revealing the key, and consequently the buffer size.
2. In general authenticating the ciphertext provides better security
(as far as authentication is concerned) than authenticating 
the plaintext.

On the other hand, for the purpose of non-repudiation, the signature-based
SrA methods are better applies to the plaintext, rather than the
ciphertext.

However, I totally agree with your aversion towards options.
In fact, in case we decide we don't care about non-repudiation then 
I see no reason not to do what you suggest - i.e., GA[SrA[ENC[DATA]]].
And I'm not sure we should worry too much about non-repudiation,
at least not in the network layer...

What do people say.

Ran