Subject: RE: [MSEC] WG Last Call for RSA-signatures draft (closing date Friday20 August 2004)

From: <[email-masked]>
Date: Mon, 9 Aug 2004 10:56:58 -0400

In the past 1+ year I have familiarized myself with the problem (read the
literature and monitored this list), being able to do data source authentication 
without digital signatures was the basic problem definiton (including the book 
co-authored by you).

Now in IETF-60 we did a 180 degree turn and are saying digital signatures per
packet are not that bad after all. How do we justify this turn? Processing power
is increasing? Well, that means symmetric HMAC can be done even faster.

The trade-offs are listed reasonably well in the draft. Are we going to propose 
something else for endpoints which do not have enough processing power?

Denial of Service attack from outside the group is fixed by a group-wide symmetric
HMAC. But there is no mention of DoS attacks possible from within the group
sending bad/spoofed signatures.

In presence of multiple senders, how would a receiver pick the right public key.
This is not made explicit in the document. I would expect that from a document in
the last call.

One factual inconsistency: Section 2.0 mention minimum RSA modulus size 
496 bits(62 bytes). But Section 3.0 implies minimum being 61 bytes.

Atul

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Thomas
> Hardjono
> Sent: Friday, August 06, 2004 2:11 PM
> To: MSEC MSEC
> Cc: [email-masked]
> Subject: [MSEC] WG Last Call for RSA-signatures draft (closing date
> Friday20 August 2004)
> 
> 
> 
> 
> Folks,
> 
> As mentioned in the MSEC WG meeting this week at IETF60, the 
> RSA-signatures
> draft is ready for WG Last Call.
> 
> You can get the latest version here:
> http://www.ietf.org/internet-drafts/draft-ietf-msec-ipsec-sign
atures-01.txt

Therefore, we would like to begin WG Last Call for this draft, with a closing
date of Friday 20 August 2004.

Please send your comments to the list a.s.a.p.

Regards.

thomas
------

		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Mon, 09 Aug 2004 11:21:40 -0400

First, I am not trying to address anything specific to this draft's last 
call, except that we will have more than one source auth schemes 
standardized by MSEC: TESLA is one, digital signatures is another. 

As I noted at the meeting and to Thomas and Brian separately, I am 
currently writing an I-D to work with the various hash chaining schemes 
proposed in the literature.  Simply put each packet will have the 
capability of carrying one or more hashes, and there will be a signature 
packet.  Hash chaining will reduce the processing requirements, but does 
not seem to alleviate the per-packet overhead.  Contributions are 
welcome from anyone interested in that effort; please send an email to 
the list or to me.  Once I have sufficient text, I will submit the I-D 
and ask for a WG status TBD. 

thanks,
Lakshminath

---

From: Hugh Harney <[email-masked]>
Date: Mon, 9 Aug 2004 13:40:22 -0400

Lakshminath,

I think the community would benefit from having all the potential 
source auth schemes defined in standards.

Hugh

On Aug 9, 2004, at 11:21 AM, Dondeti, Lakshminath wrote:

> First, I am not trying to address anything specific to this draft's 
> last call, except that we will have more than one source auth schemes 
> currently writing an I-D to work with the various hash chaining 
> schemes proposed in the literature.  Simply put each packet will have 
> the capability of carrying one or more hashes, and there will be a 
> signature packet.  Hash chaining will reduce the processing 
> requirements, but does not seem to alleviate the per-packet overhead.  
> Contributions are welcome from anyone interested in that effort; 
> please send an email to the list or to me.  Once I have sufficient 
> text, I will submit the I-D and ask for a WG status TBD.
> thanks,
> Lakshminath
>
>
>> literature and monitored this list), being able to do data source 
>> authentication without digital signatures was the basic problem 
>> definiton (including the book co-authored by you).
>>
>> The trade-offs are listed reasonably well in the draft. Are we going 
>> to propose something else for endpoints which do not have enough 
>> processing power?
>>
>> One factual inconsistency: Section 2.0 mention minimum RSA modulus 
>> size 496 bits(62 bytes). But Section 3.0 implies minimum being 61 
>> bytes.
>>
>> Atul
>>
>>
>>
Hugh Harney							Sparta, Inc.
[email-masked]						7075 Samuel Morse Drive
(410) 872-1515 x203					Columbia, MD, 21046

---

From: George Gross <[email-masked]>
Date: Mon, 9 Aug 2004 14:42:41 -0400 (EDT)

Hi,
	inline below....

> source auth schemes defined in standards.

I largely concur with this statement, but with the following caveats:

First, there should be only one MUST implement standard source
authentication method within the context of a particular key management
protocol. With respect to GSAKMP IPsec, I have not yet decided which
method to profile for use with multicast ESP, but I do anticipate
specifying one as the MUST implement. This would include those parameters
needed to be declared in the policy token, and those needed in the SAM
message, and finally a pointer to the relevant ESP protocol spec.

Second, the IETF has a standing policy of not mandating any "must
implement" security standards that have IPR encumberances (options that
have IPR are okay). In this regard, RSA signatures and TESLA to my
knowledge are not so encumbered, whereas several flavors of hash chain
source authentication fall within the domain of the Rohgati patents.

Third, perceived overhead is in the eye of the beholder. As a data point,
consider the crypto++ library benchmarks published by Wei Dai. For version
5.2, the RSA 1024-bit signature generation on a 2.1 GHz Pentium under
Win/XP SP1 incurs 4.65 milliseconds overhead. The RSA signature
verification incurs 0.19 milliseconds overhead. I have not attempted to
run similar tests for the "weak" 512-bit RSA key length proposed in
Brien's draft, but clearly RSA signature has the benefit from placing the
computational burden on the speaker, and conversely making the receiver's
job easy. Of course, it is extremely subjective how to answer the
question: can your multicast application accept this level of overhead?

Although TESLA promises lower computational overhead than RSA signature,
the latency incured at the receivers who await an authentication key's
disclosure may be unacceptable to the application. Again, it is subjective
how to even set this disclosure delay correctly for the group (i.e. how do
you measure a network's propagation delays dynamically?) and whether the
application du jour can accept that delay. My misgiving is that we do not
yet have much empirical experience with TESLA to engineer its performance
correctly. Aside from that, TESLA does not offer a non-repudiation
property, which may not fulfill some application's security policy.

So I see value in having multiple source authentication schemes in the
MSEC standards toolkit. For inter-operability, we need at least one such
scheme being *required* to be implemented in everyone's multicast security
toolkit for ESP (and another for SRTP for that matter).

br,
	George

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 09 Aug 2004 22:00:53 -0700

Atul,

Actually, the issue is more related to practicalities.

We need a solution that can work today and is understood by the broader 
security community in the IETF (e.g. IPsec WG, RMT WG).

This does not mean that MSEC is abandoning other solutions.  In fact, we 
are still going to work on TESLA (ps. the TESLA-Intro draft has already 
done WG Last Call). We are waiting for the TESLA-specs draft to be 
finalized and the authors OK with it going Last Call.

Bear in mind MSEC discovered that there is no single solution that fits 
all, since there are many application-areas needing source-authentication 
(e.g. routing, mobile, satellite), each with differing constraints.

So if there are other solutions out there, MSEC is open to using them and 
standardizing them.

thomas
------

At 8/9/2004||07:56 AM, [email-masked] wrote:

>authentication

---

From: Brian Weis <[email-masked]>
Date: Mon, 09 Aug 2004 22:38:36 -0700

Hi Atul,

Thanks for your good comments ... please see my replies below.

>is increasing? Well, that means symmetric HMAC can be done even faster.
As others have stated, there are other methods than digital signatures 
(e.g., TESLA). However, those methods often assume a stream of data. 
Applications that do not have a steady stream of data can benefit from 
digital signatures.

>sending bad/spoofed signatures.
Good point ... I'll add a discussion pointing out that attacks from 
within the group cannot be mitigated by the HMAC.

>This is not made explicit in the document. I would expect that from a document in
Section 5.0 points out that the key should be downloaded during key 
management. It is implied that the public key is associated with a 
particular SA. I'll make that more explicit.

>496 bits(62 bytes). But Section 3.0 implies minimum being 61 bytes.
Thanks for pointing this out.

Brian

-- 
Brian Weis
Advanced Security Development, ITD, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: "David A. McGrew" <[email-masked]>
Date: Tue, 10 Aug 2004 05:03:41 -0700

Thomas,

On Aug 9, 2004, at 10:00 PM, Thomas Hardjono wrote:

> We need a solution that can work today and is understood by the 
> broader security community in the IETF (e.g. IPsec WG, RMT WG).
>
> This does not mean that MSEC is abandoning other solutions.  In fact, 
> we are still going to work on TESLA (ps. the TESLA-Intro draft has 
> already done WG Last Call). We are waiting for the TESLA-specs draft 
> to be finalized and the authors OK with it going Last Call.

I think that this is a good plan.  There will probably be application 
designers who consider using RSA-signatures in ESP, and who have never 
heard of TESLA, but then are led to TESLA from reading that draft.

David

>
> Bear in mind MSEC discovered that there is no single solution that 
> fits all, since there are many application-areas needing 
> source-authentication (e.g. routing, mobile, satellite), each with 
> differing constraints.
>
> So if there are other solutions out there, MSEC is open to using them 
> and standardizing them.
>
>
> thomas
> ------
>
>
>
>> to propose
>> size

---

From: canetti <[email-masked]>
Date: Tue, 10 Aug 2004 09:23:44 -0400 (EDT)

George,

I agree that there should be one MUST implement source authentication
scheme. Probably the best candidate is RSA signatures - despite its
drawbacks, it is by far the simplest to implement and to deploy.
Also, once we have alternative signature schemes in the future it will
hopefully be relatively easy to switch.

BTW, the main drawback of RSA sigs is not the verification overhead (this
can be done even faster than what you say, if one uses optimized versions
such as RSA with exponent 3), but rather the bandwidth overhead: 128 bytes
per packet for RSA1024, as opposed to around 24 bytes for TESLA.

Ran

---

From: Hugh Harney <[email-masked]>
Date: Tue, 10 Aug 2004 11:34:33 -0400

George,

comments in line.

On Aug 9, 2004, at 2:42 PM, George Gross wrote:

> protocol.

I think the singular MUST should refer to the data layer protocol 
specification. GSAKMP can support many data layer protocols and each 
can have a different source auth protocol specified as MUST in the 
different specifications.

> With respect to GSAKMP IPsec, I have not yet decided which

If the MUST implement source auth mechanism is specified in it's own 
standard, I'd think it would be better to reference that standard for 
the policy transferal mechanism. For example, if TESLA specified it's 
own payloads to be passed in GSAKMP for TESLA unique policy (latency 
info), then I'd think it would be preferable to use the same TESLA 
mechanisms.
> source authentication fall within the domain of the Rohgati patents.

Yup, the IETF's policy is pretty clear. I'm not sure of the span of the 
Rohgati patents.

>>>> In the past 1+ year I have familiarized myself with the problem 
>>>> (read
>>>> the
>>>> HMAC. But there is no mention of DoS attacks possible from within 
>>>> the
>>>> group
>>>> This is not made explicit in the document. I would expect that from 
>>>> a
>>>> document in
>>>> the last call.
>>>>
>>>> Therefore, we would like to begin WG Last Call for this draft, with 
>>>> a
>>>> closing
Hugh Harney							Sparta, Inc.

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Tue, 10 Aug 2004 11:47:49 -0400

I think it is better to suggest simple schemes as MUST in GKM protocol 
specifications (e.g., RSA-sign as Ran noted).

As I noted on the list before, I saw some old patents on USPTO which I 
thought cover LKH (I am not a lawyer).  We have not seen any IPR 
statements from LKH to the IETF to my recollection.  Just noting here, 
so we don't require LKH in any of the GKM protocol specifications.

Besides, as Thomas noted, different app scenarios require different 
protocols/schemes/mechanisms.  That is applicable to rekey protocols, 
source authentication schemes, reliable transport protocols etc.

regards,
Lakshminath

---

From: George Gross <[email-masked]>
Date: Tue, 10 Aug 2004 15:03:17 -0400 (EDT)

Hi Lakshminath,

> specifications (e.g., RSA-sign as Ran noted).

agreed. RSA signature seems like a reasonable candidate for this role. I
anticipate reviewing and posting comments before the last call elapses....

> so we don't require LKH in any of the GKM protocol specifications.

I had brought the question of LKH IPR to the MSEC list last year. See the
e-mail thread in the archive dated July 21st 2003, with the Subject line
"A few questions on GSAKMP (long)". My take away from that discussion was
that Sun's patents were pre-dated by prior art and publications. But as
Mark has pointed out in another e-mail today, IPR can be claimed at any
time from any point of the compass, not just the USPTO.  That said, in the
GSAKMP IPsec profile I have nominated LKH as a MUST, and it is fully
spec'd as an option in the GSAKMP base specification appendix 1.  No
comparable protocol spec exists for OFT (or any other group rekey
protocol/algorithm) AFAIK.

br,
	George

<snip>