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

From: Mark Baugher <[email-masked]>
Date: Mon, 04 Nov 2002 08:01:41 -0800

hi Martin

At 04:22 PM 11/4/2002 +0100, Euchner Martin ICN M SR 3 wrote:
>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.

Yes, this is the order applied at the sender.  The order at the receiver is 
of course the reverse and this allows a relatively cheaper message 
authentication code to be applied prior to the more expensive decryption 
operation.  This lessens the effects of denial of service attacks that 
attempt to force receiver decryptions of bogus packets.

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

This is true only when the SrA transform is a digital signature.  This is 
not what we intend in general in 
http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-msec-mesp-00.txt.  There 
is no restriction that SrA must be an internal transform though Scott 
Fluhrer recommends that TESLA be protected by a MAC (GA) and we need to 
consider this.

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

TESLA is an SrA transform that is not more expensive than a MAC in terms of 
computation.  It could be expensive in terms of receiver memory.  So what 
you say is true for decryption (GS) and digital signature source 
authentication.

>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

We perhaps don't state this clearly in the current I-D.  The order is 
always INT, ENC, EXT.  But SrA is not necessarily an internal 
authentication transform (INT).

>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.

The I-D essentially says what you are saying (if somewhere the I-D equates 
SrA with INT, then this is an error).  But there may be a need to protect 
TESLA with a MAC since TESLA cannot authenticate messages until a key is 
revealed.  Over that interval, the receiver will be caching packets that 
are addressed to the group and appear to have a valid source address.  This 
is a denial of service attack that can be partly mitigated by the MAC; when 
GA is applied to TESLA, only group members can spoof the GA.  If the TESLA 
authentication subsequently fails, then the receiver recognizes that its 
attacker holds the group authentication key.

> >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.

I assume by "internal attacker" you mean "group member."  We should keep in 
mind that the authentication needs to be secure independently of whether 
encryption is applied to the packet or not.

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

It is always an option that the INT parameters are not encrypted.  We 
cannot require encryption for internal or external authentication.

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

I think we need to be more clear in section 4.

>Some other comments:
>* Why does MESP not support AH (e.g. MAH)? Is there any reason?

It's not clear that IPsec is going to continue to support AH.  What we lose 
without AH is authentication of certain IP header fields.  Some claim that 
this is a marginal benefit given the added costs of having a second 
security protocol, NAT traversal, and some other issues.  Regardless of the 
future of AH, it makes sense to start with one protocol for multicast 
extensions and we have chosen ESP because it has both encryption and 
(group) message authentication.  (This is actually the course recommended 
to IRTF SMuG in the original MESP/AMESP draft document).

>* 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.

I read the old TESLA I-D prior to the posting of the latest I-Ds.  I think 
TESLA should be an internal transform based on Scott's observations.

thanks, Mark

>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

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 04 Nov 2002 10:27:25 -0500

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

Mark Baugher wrote:
> Yes, this is the order applied at the sender.  The order at the receiver 
> is of course the reverse and this allows a relatively cheaper message 
> This is true only when the SrA transform is a digital signature.  This 
> is not what we intend in general in 
> http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-msec-mesp-00.txt.  
> There is no restriction that SrA must be an internal transform though 
> Scott Fluhrer recommends that TESLA be protected by a MAC (GA) and we 
> need to consider this.
> 
> 
> TESLA is an SrA transform that is not more expensive than a MAC in terms 
> of computation.  It could be expensive in terms of receiver memory.  So 
> what you say is true for decryption (GS) and digital signature source 
> authentication.
> 
> 
> The I-D essentially says what you are saying (if somewhere the I-D 
> equates SrA with INT, then this is an error).  But there may be a need 
> to protect TESLA with a MAC since TESLA cannot authenticate messages 
> until a key is revealed.  Over that interval, the receiver will be 
> caching packets that are addressed to the group and appear to have a 
> valid source address.  This is a denial of service attack that can be 
> partly mitigated by the MAC; when GA is applied to TESLA, only group 
> members can spoof the GA.  If the TESLA authentication subsequently 
> fails, then the receiver recognizes that its attacker holds the group 
> authentication key.
> 
> 
> I assume by "internal attacker" you mean "group member."  We should keep 
> in mind that the authentication needs to be secure independently of 
> whether encryption is applied to the packet or not.
> 
> 
> It's not clear that IPsec is going to continue to support AH.  What we 
> lose without AH is authentication of certain IP header fields.  Some 
> claim that this is a marginal benefit given the added costs of having a 
> second security protocol, NAT traversal, and some other issues.  
> Regardless of the future of AH, it makes sense to start with one 
> protocol for multicast extensions and we have chosen ESP because it has 
> both encryption and (group) message authentication.  (This is actually 
> the course recommended to IRTF SMuG in the original MESP/AMESP draft 
> document).
> 
> I read the old TESLA I-D prior to the posting of the latest I-Ds.  I 
> think TESLA should be an internal transform based on Scott's observations.
> 
> thanks, Mark
> 
> 
>> With kind regards
>>
>>
>> Martin Euchner.

---

From: Mark Baugher <[email-masked]>
Date: Mon, 04 Nov 2002 10:48:37 -0800

We had SrA always be an internal authentication transform (INT) in an 
earlier version of this draft but changed it so as to not unduly restrict 
source message authentication options.  Following Scott's observation and 
some more consideration, I'm inclined to agree with you.

Mark

At 10:27 AM 11/4/2002 -0500, Lakshminath Dondeti wrote:
>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.
>
>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.
>
>>equates SrA with INT, then this is an error).  But there may be a need to 
>>protect TESLA with a MAC since TESLA cannot authenticate messages until a 
>>key is revealed.  Over that interval, the receiver will be caching 
>>packets that are addressed to the group and appear to have a valid source 
>>address.  This is a denial of service attack that can be partly mitigated 
>>by the MAC; when GA is applied to TESLA, only group members can spoof the 
>>GA.  If the TESLA authentication subsequently fails, then the receiver 
>>recognizes that its attacker holds the group authentication key.
>>
>>Regardless of the future of AH, it makes sense to start with one protocol 
>>for multicast extensions and we have chosen ESP because it has both 
>>encryption and (group) message authentication.  (This is actually the 
>>course recommended to IRTF SMuG in the original MESP/AMESP draft document).
>>