Subject: [MSEC] comments on IPSEC RSA signature draft

From: George Gross <[email-masked]>
Date: Mon, 16 Aug 2004 10:56:41 -0400 (EDT)

Hi Brien,

	Generally this draft is in good shape, and I'm glad to see it
moving forward. I'm still working through how I would implement this
draft, and that process may uncover additional topics for discussion. In
the meantime, here's what I found on my first read:

ISSUE 1: In the ESP/AH RSA signatures draft section 2, there is paragraph
that begins with the sentence:

   "Ephemeral RSA key pairs generated for use during the lifetime of an
   SA may be generated."

I think I understand what this above sentence intends, but it is written
in passive voice and it leaves some important things unsaid. As a
clarification, how about replacing it with the following text:

"The signing party MAY generate multiple ephemeral RSA key pairs during
the SA lifetime. The public key's distribution mechanism and its
replacement interval are a local policy matter. The SA key management
protocol MUST provide a certification mechanism for the ephemeral RSA
public key that complies with the profile in section 5.X. The signature
verifiers MUST use that certification mechanism to assure that they use
only an authentic and currently valid signature public key."

The new sub-section 5.X would be entitled "Public Key Certification
Mechanism Requirements" or something like that. See ISSUE 3 below.

ISSUE 2: Does the same ESP SPI get used after each time that the key pair
has changed? I'm wondering if that would make sense. Otherwise, the
verifier would not know when the ESP packet stream has made its transition
to a new public key. Out of order packet delivery would magnify this
problem.  Alternatively, the ESP authenticator must include a public key
identifier field, which might be a good thing to introduce anyway.

ISSUE 3: Ephermeral RSA key pairs creates a tough key management problem.
I realize it is too heavyweight to require that there be a RFC3280
compliant certificate created for each ephermeral RSA key pair. OTOH, I
think we have the obligation to say how do we handle:

 - key revocation in the event of private key compromise?

 - verify the validity period for the public key's lifetime?

 - thwart an active attacker that partitions the group during
   the transition between public keys. May be an unlikely case,
   but if the attacker withheld the "new public key" announcement from
   the group long enough, the attacker could crack the signature
   private key and then forge packet signatures to the sub-group
   under the attacker's control.

 - the public key's validation to a trust anchor when it is a
   traditional X.509 signature certificate key pair rather than
   an ephermeral key pair? I'm assuming you may use your X.509
   EE signature cert, this is not prohibited, right?

Specifying these key management mechanisms may be out of scope for this
spec, but it would be good for this document to mandate a profile
and requirements pointing at the mechanisms that handle these issues.
I realize that the intent here is to get the benefit of "lightweight"
public key cryptography without the baggage of PKI. So I agree that this
flavor of digital signature ESP/AH is an important design goal.

OTOH, I am concerned that we'll create a potential inter-operability
problem unless we explicitly couple the RSA public key to something
analogous to the PKIX standards that can manage that ephermeral
public key's lifecycle.

ISSUE 4: In section 5 there is the statement:

   "Use of this transform with a pair-wise key management system such as
   the Internet Key Exchange [IKEv2] is NOT RECOMMENDED.  The value of
   using this transform for a pair-wise connection is limited,
   considering the performance impact."

This statement precludes a policy that uses a digital signature for its
non-repudiation characteristic. This may be useful in an application for
which legal or economic policy requires that it can substantiate that only
one of the two parties could have sent the signed message. I would suggest
revising the text to say that local policy may elect to use this mechanism
for non-repudiation provided the public key length is increased for the
(presumably) longer period that the signature must be kept secure.

br,
	George

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

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Mon, 16 Aug 2004 13:42:47 -0400

My biggest concern with signing and hash chaining of IPsec packets is 
that we would be providing non-repudiation without the user asking for 
that capability (or burden :-)).  Like many (they said it before I did) 
in the IPsec world, I believe non-repudiation is not an IP layer 
feature/requirement.  It is an application layer feature/requirement.

So, I think the "NOT RECOMMENDED" should stay.

thanks,
Lakshminath

---

From: George Gross <[email-masked]>
Date: Mon, 16 Aug 2004 12:48:50 -0400 (EDT)

Hi Lakshminath,

On Mon, 16 Aug 2004, Dondeti, Lakshminath wrote:

> that capability (or burden :-)).

Not sure I understand the "burden" you are referring to. Both parties that
entered into this SA negotiated and agreed to its proposals, which in this
case is *their* pair-wise policy, they decided it is not a burden. For
IPsec with IKE-v2, digital signature authentication remains optional,
whereas HMAC-SHA1 and its cousins are mandatory to support.

In particular, couldn't IPsec set up two nested SA, and only use RSA
signature on the inner ESP header, but not use the inner ESP header on
every packet, just use it occasionally for the policy defined "critical
packets" in the application's data stream?

> Like many (they said it before I did)

Once we put a tool like RSA signature ESP in the IPsec toolkit, it is no
longer feasible for the IETF to prescribe its usage policy to its users
unless you can justify how the tool could negatively impact security if
misused. I do not see that being the case here.

are you saying that the non-repudiation "burden" really exists in a legal
sense? do we add a health warning label like "Don't use this tool if you
anticipate later get entangled in a court of jurisprudence for whom this
signature would be used as evidence in its proceedings." i.e. don't sign
if you don't know who could use it against you ;o)

	George

---

From: Brian Weis <[email-masked]>
Date: Tue, 17 Aug 2004 13:07:19 -0700

Hi George,

Regarding non-repudiation: I did not intend for the RSA Signatures draft 
to convey that! Nowhere is non-repudiation claimed in the IPsec 
architecture, or in any of the documents that fit within that framework 
(including IKE and IKEv2).  Digital signatures are intended for 
authentication. This draft should follow suit.

>whereas HMAC-SHA1 and its cousins are mandatory to support.
There is a certainly a processing burden. The object of using RSA 
Signatures as an IPsec transform is to provide source origin 
authentication. In the absence of non-repudiation, there is no source 
origin authentication advantage for a pair-wise IPsec SA to use a 
digital signature.  To the contrary: there is a significant processing 
penalty to digital signature in the pair-wise case. Hence the guidance 
to the unwary. :-)

>packets" in the application's data stream?
You're basically describing using two sets of policy for one set of 
traffic selectors. In general, that's possible. but the encapsulating 
device must have a process for deciding which set of policy to use, and 
this may be problematic to implement. I wouldn't recommend it.

>sense? 
IMO, there are always legal implications to claiming non-repudiation.

>do we add a health warning label like "Don't use this tool if you
:-) It's just easier to not claim it.

>>>(presumably) longer period that the signature must be kept secure.
I prefer to leave the NOT RECOMMENDED statement, unless there is a WG 
consensus that it should be changed.

Thanks,
Brian

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

---

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

Hi Brian,

> authentication. This draft should follow suit.

I understand your intention, but those pesky lawyers may hijack your
mechanism at any key lengths and interpret the digital signature as being
a legal signature!

This question's answer is shades of grey: at what key strength does a RSA
signature transition from a source authentication mechanism into one that
also assists the legal process of non-repudiation? Even at smaller key
lengths, it may be relevant to that legal process because there is a
window of time after the signature where it could argued that an adversary
would not have a reasonable technical means to break the private key and
forge the signature. So an observer within the cryptographic group could
testify that its timestamped records show that the signature was within
that "non-repudiation" window.

=> that said, digital signatures do NOT by themselves provide
non-repudiation, they are only evidence in the non-repudiation legal
process and a given signature may or may not persuade that court that the
signature was relevant and binding to the signer.

We can not and should not attempt to answer this question here, we'd chase
out tail forever debating it. The RSA signature draft can only bring the
above issues to the implementors and the users attention, and let them
devise their policy in the context of their local legal jurisdiction.

what the RSA signature IPsec draft should do is require a management
interface that allows alot of control over the RSA key strength, and
specify it such that both signing endpoints and verifying endpoints will
inter-operate. I recommend a range from 512 to 2048 bits in increments of
64 bits (or whatever).

replies to a few loose ends inline below...

> penalty to digital signature in the pair-wise case. Hence the guidance

as discussed above, there is no exemption that prevents a signature from
being considered as a legal signature. Again, this is a policy decision.
The signer party may explicitly want non-repudiation and the processing
cost is moot. Example: I send a multicast message to an auction group
containing my $$$ bid. Or I send it to my peer in a pair-wise SA.  Either
way, I'm okay with it being legally binding, that is my intent in this
context.

> this may be problematic to implement. I wouldn't recommend it.

I certainly can envision a host-based IPsec subsystem with an API that
allows an application layer process to delegate authority to the IPsec
subsystem sign a packet on its behalf. For an example of another mechanism
that can support IPsec signature authorization, you could use an attribute
certificate. So I do not consider it to be problematic to implement.

> consensus that it should be changed.

A more accurate recommendation is to say that RSA signatures may have
legal conotations in some jurisdictions. Therefore, when setting the RSA
key strength policy, consider that factor if it is relevant in your
jurisdiction. Saying anything else, including the above "NOT RECOMMENDED"
statement is attempting to tell the users how they implement policy for
the RSA signature, which the IETF does not do in standards.

br,
	George

---

From: Brian Weis <[email-masked]>
Date: Tue, 17 Aug 2004 17:15:50 -0700

Hi George,

Thanks for your detailed comments. Replied are inline below.

>   "Ephemeral RSA key pairs generated for use during the lifetime of an
There is a slight typo in this original text, for which I apologize. It 
did not mean to imply that *multiple keypairs* would be used during the 
life of a single SA. Rather, a key pair may be generated for the express 
use of an SA. But that's just a recommendation. The keypair could be a 
long term keypair. But if so, I do not assume the need for a 
certificate. (This is discussed later in these comments.)

>Mechanism Requirements" or something like that. See ISSUE 3 below.
I like the idea of "The public key's distribution mechanism and its 
replacement interval are a local policy matter." But your text 
additionally brings in some new concepts that I'm not quite ready to 
embrace. I do not believe that a certification mechanism is required. 
Section 5 lists the mechanism that should be used for specifying the 
public key, which is to deliver it during group key management. Since 
this is a per-SA attribute, it gets deleted when the SA expires, and the 
receiver need pay it no more mind.

I have not specified how it would work outside of the group key 
management case, because of the  NOT RECOMMEND guidance (to which you 
object in ISSUE 4).

I see that Section 5 of the document needs to be clearer with respect to 
the handing of the public key.

>identifier field, which might be a good thing to introduce anyway.
This issue is moot, due to a misunderstanding of my buggy text. Again, 
my apologies.

> - key revocation in the event of private key compromise?
This is no more an issue than if an AES key was compromised. Deletion of 
the IPsec SA would be the mechanism.

>   EE signature cert, this is not prohibited, right?
The above three issues assume the  presence of a certificate. Without a 
certificate, there is no issue.

>analogous to the PKIX standards that can manage that ephermeral
If a PKI was needed, I would definitely refer to PKIX document. My goal 
is to be so simple as to not require any sort of certificate 
infrastructure, just bare public keys distributed on a per-SA basis.

I'll start a new thread on this list shortly to describe with some 
background on why I am promulgating such a limited vision.

Thanks,
Brian

---

From: Brian Weis <[email-masked]>
Date: Tue, 17 Aug 2004 18:51:12 -0700

Hi George,

George Gross wrote:

>out tail forever debating it. 
>
Agreed.

>The RSA signature draft can only bring the
I see no reason why the draft needs to discuss non-repudiation or other 
legal issues with public keys. For example, RFC 2409 (which also used 
digital signatures for authentication) was not required to make such a 
statement.

>inter-operate. I recommend a range from 512 to 2048 bits in increments of
This is done. Section 2 describes key sizes. Section 5 defines the SA 
management interface controlling the key strength.

[snip]

>certificate. So I do not consider it to be problematic to implement.
By problematic, I was implying that existing mechanisms (including the 
pervasive PF_KEY API used to push IPsec SAs into the kernel) would not 
support this behavior.

>jurisdiction. 
This is not a statement I recall in any IETF standard, and I don't think 
is needed here.

>Saying anything else, including the above "NOT RECOMMENDED"
Actually, I believe this recommendation is in line with RFC 2119, which 
does describe the use of "NOT RECOMMEND":

"4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label."

The "full implications [which] should be understood and the case 
carefully weighed before implementing" are defined as being performance 
related. (Note that this is not the same restriction as MUST NOT, which 
is a  statement that even I would find objectionable.)

Thanks,
Brian

---

From: George Gross <[email-masked]>
Date: Wed, 18 Aug 2004 08:26:49 -0400 (EDT)

Hi Brian,

I hate to belabor this thread, but some things are still dangling...

> receiver need pay it no more mind.

The IPsec RSA signature draft is under specified for its requirements on
the group key management protocol, which is taking on the responsibility
as the "public key certification"  mechanism. I would like to see the
draft's section 5 require that the group key management protocol specify
the following things about the public key:

1. In the case where the Group Speaker generates its own public/private
key pair, the group key management protocol MUST include a proof of
possession of the signature private key exchange between the GC/KS and the
Group Speaker.

2. The public key MUST be delivered to the group membership by the group
key management protocol using an authenticated certification mechanism.
For example, in GDOI this certification is the inclusion of the public key
as signed data under the ISAKMP Signature payload [RFC2408 section 3.12]
signed by a trusted GC/KS.

Incidently, the RFC2408 text in section 3.12 *explicitly* says that the
ISAKMP signature payload can be used in non-repudiation services. So the
IPsec RSA signature public key is implicitly a certified key that can
also offer non-repudiation services ;o)

3. The public key's validity period is the same as the SA lifetime, and
there MUST be an accurate mechanism for all of the group members to detect
when the public key has expired. When the validity period expires, any
signature using that public key must be ignored, the packet discarded, and
the SA deleted.

4. The group key management protocol SHOULD have a mechanism to announce
that the private signature key has been compromised before the end of its
validity period.  This gives the group members the ability to
examine/audit recently received datagrams and detect those that might be
forgeries and potentially disregard them. Unlike a group traffic
encryption key, the signature is a legal instrument that has this
additional responsibility (even if this working group is uncomfortable
with that status).

5. The group key managment protocol's management interface MUST have the
ability to specify RSA key lengths ranging from 496 bits through 2048
bits. Note that the current IPsec RSA signature text in section 5 places
no "MUST implement" obligation on the implementations to expose this
parameter to be configurable.

6. The public key MAY be the public key from an X.509 end entity signature
public key certficate. When it is this type of public key, then the group
members MUST implement X.509 certificate validation in compliance with the
cryptographic group's policies.

> the handing of the public key.

If you could please include language similar to what I've outlined above,
then that would go a long way towards closing this issue.

<snip ISSUE 2>
> the IPsec SA would be the mechanism.

I see digital signature compromise as having additional responsibility. At
the least, the key management protocol SHOULD have a mechanism to alert
the signature verifiers of the compromise. As a matter of policy, you
would not choose to use signatures with their computational overhead
unless the signatures have additional importance (i.e. legal, economic, or
system control). So compromise makes recent signature suspect. What one
does after receiving that alert is application policy specific.

> certificate, there is no issue.

I respectfully disagree, these are real key management issues, and it is
within scope of this draft to prescribe how they are managed. See above
for specifics.

<snip>
> infrastructure, just bare public keys distributed on a per-SA basis.

Your basic premise is sound, but the draft still must specify the key
management requirements as stated above. Granted, it is simpler than PKIX,
but I am saying that there is a checklist that group key management
protocol implementors MUST satisfy to use IPsec RSA signature securely.

hth,
	George

<snip ISSUE 4>

---

From: Brian Weis <[email-masked]>
Date: Wed, 18 Aug 2004 11:50:02 -0700

Hi George,

Lets level set. What are these public keys being used for? They have one 
purpose in life: To validate an Integrity Check Value (ICV) placed in an 
IPsec encapsulated data packet. The goal of any ICV validation is to 
ensure that the packet came from a valid sender.

 In the case of group traffic, a receiver sometimes whats to know that 
the packet came from "the valid sender" rather than "a valid sender". In 
that case, they  want the ICV validation to additionally provide Source 
Origin Authentication. But they still just want to ensure that "the 
valid sender" created an IPsec encapsulation. Once an ICV is verified, 
the ICV value (e.g., signature) is discarded, as it serves no further 
purpose. When the IPsec SA expires, then the mapping of any particular 
key used to validate the ICV (e.g., the public key) is also discarded. 
There is not explicit traceability, any more than there is any explicit 
traceability of which secret key was used for the SA. The receiver 
expects nothing more from a digital signature based ICV than an HMAC in 
this respect.

This is a novel use of digital signatures, and this simplicity is 
non-intuitive and easy to forget. But the simplicity of purpose also 
frees us from many of the concerns of digital signatures: requirements 
for certificates, concerns of non-repudiation, etc. This is why I object 
to adding more requirements on these public keys to the draft.

I will agree that there are some key management issues which have not 
been specified. (Atul pointed this out too.) But they belong in a key 
management document. For example, GDOI needs some updates to support 
this: it needs an addition in its namespace in the KD payload. It also 
could also describe some of the things you mention below, such as if 
there is a known lifetime for the key (e.g., from a certificate), that 
is must not use that key beyond the lifetime in the certificate. But 
these firmly belong in the key management draft, not in the IPsec 
transform draft describing how the RSA algorithm is applied to an ICV.

Thanks,
Brian