Subject: [MSEC] Why the rsa-signatures draft doesn't explicitly deal with PKI issues

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

There have been some good questions around the specifications of the 
public keys with respect to draft-ietf-msec-ipsec-signatures-01.txt. The 
draft says very little regarding how the public keys are derived, 
certified, validated, etc., and I'd like to provide some background as 
to why.

1. Simplicity. Certificates have requirements that are onerous in this 
application. Case in point: the SEND WG at one time attempted to specify 
the use of RSA signatures for per-packet authentication of IPv6 neighbor 
discovery messages. The SEND messages originally used AH. Given the SEND 
trust model, it was necessary to carry certificates in every packet 
along with the signature. This led to so many issues they eventually 
dropped the use of AH for their own packet format. These same issues 
would apply if to one degree or another if the RSA signatures draft 
explicitly supported certificates.

2. Simplicity. This document is intended to be an IPsec transform draft, 
in the spirit of RFC 2404. Parameters of keying material (in this case, 
a public key) need to be carefully described. But you will find that 
IPsec transform documents do not discuss key management, or even how the 
keys are created or obtained. Therefore it is not appropriate for the 
RSA Signatures document to get too deep into these issues. It certainly 
should not discuss PKI issues! Those belong to key management.

Because using such an expensive cryptographic transform on a data packet 
is a novelty, I did include some text giving some minimal explanation 
and guidance regarding the usage of this transform. This is the last two 
paragraphs of Section 5. This does go beyond the other IPsec transform 
drafts.

There is no reason whatsoever that public keys with certificates could 
not be used. But PKI issues around those keys belong to key management, 
not this document.

Brian

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

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

---

From: canetti <[email-masked]>
Date: Wed, 18 Aug 2004 01:07:56 -0400 (EDT)

Brian, I totally agree with your approach.
There should probably be some text in the I-D explaining this.

A couple remarks:

* We use RSA signatures for authentication. The fact that they might be
used also for non-repudiability is not a concern of this I-D. Thus, we do
not need to carry certificates around. Making sure that both parties have
the correct verification keys in  their respective SAs is the job of the
key management protocol.

* Digital signatures do not necessarily provide non-repudiation,
regardless of the length of the keys. In order to provide non-repudiation,
the public key of the signature should be appropriately certified.
In fact, if the public key to be used in the session is never
explicitly signed by the parties during the key exchange, then signing
packets with the corresponding secert key provides full repudiability
(while still providing perfectly good authentication).

Ran

---

From: George Gross <[email-masked]>
Date: Wed, 18 Aug 2004 09:03:24 -0400 (EDT)

Hi Ran,

> the correct verification keys in  their respective SAs is the job of the

okay.

> (while still providing perfectly good authentication).

Perhaps you mispoke, but in my mind an uncertified public key provides no
authentication. Are you suggesting pre-placed RSA public keys to avoid a
TTP signature on the public key?

Even if we avoid X.509 or PGP certificates, the key management protocol
still uses some method to "certify" the public key. As noted in a parallel
e-mail from me, RFC2408 section 3.12 Signature payload explicitly says
that the signature may be used in non-repudiation services. Consider the
implications for GDOI distributing the RSA public key as signed data under
the ISAKMP Signature payload's signature. The ISAKMP/GDOI signature
certifies the RSA public key and consequently we get both authentication
and non-repudiation service, not just authentication. Of course, the
caveat is that YMMV wrt/ non-repudiation in the legal sense.

In any case, my real issue is that the IPsec RSA signature draft specify
the simple set of key management requirements that MUST be implemented to
assure the secure use of a RSA public key that is not certified using
traditional PKI.

br,

	George
<snip>

---

From: Brian Weis <[email-masked]>
Date: Wed, 18 Aug 2004 10:56:57 -0700

Hi George,

>TTP signature on the public key?
Pre-placed manually-entered RSA public keys would indeed be another  key 
management alternative. I don't think it's a particularly good idea, but 
someone could do it. Recall that the RSA Signatures draft lives within 
the the RFC 2401 framework. In order for any IPsec implementation to be 
in compliance with RFC 2401 they are required to support manual keyed 
SAs. See Section 4.6 (as well as other sections) of RFC 2401.

This is an artifact of writing a draft that fits into the IPsec 
framework, which is the sole goal of this document.

>caveat is that YMMV wrt/ non-repudiation in the legal sense.
Most usages of the word "certification" in the PKI world that I've 
observed describe this as a specific claim that a public key belongs to 
an identity, and the vehicle used to prove that claim is a public key 
signature. In your example, the ISAKMP/GDOI signature doesn't make any 
particular claim of validity of that public key, it just signs it as 
data, with the purpose of authenticating the entity sending the data. I 
really don't see where the non-repudiation comes in.

Thank you  for pointing out that ISAKMP mentions non-repudiation. But 
"may" does not mean "it could possible be, so you'd better assume that 
it is".

Brian

---

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

Hi Brian,

> framework, which is the sole goal of this document.

I recognize that preplaced public keys are an alternative, but in the
context of this thread they are not part of the main usage case.

> signature.

Clearly, we are dealing with certification outside of traditional PKI
standards, but it is certification of the public key to a particular
identity none the less. Otherwise, MITM attacks make the public key
useless for source authentication.

 > In your example, the ISAKMP/GDOI signature doesn't make any
> data,

I do not think so. ISAKMP is not signing just any data here. It is putting
the RSA signature public key within the Signature payload's signature
scope. This is tantamount to asserting "I certify that this RSA public key
is authentic for the SA Group Speaker", along with the other SA keying
material and attributes. If the GC/KS does not vouch for the Group Speaker
identity represented by the public key, then that key's signature is
useless for authentication. In effect, the GC/KS becomes a CA.

 > with the purpose of authenticating the entity sending the data. I

As I've explained on other occasions in this thread, much as we may want
to disassociate the RSA signature from non-repudiation, the legal
community gets to say otherwise. In this context, a chain of trust exists
for the public key that could be used not only for authentication but also
for non-repudiation services. The chain of trust spans the certificate
path from root CA to the GC/KS and then from there the GC/KS signature of
the Group Speaker public key.

We can tip-toe past this by not saying anything in the draft (unlike
RFC2408), but the non-repudiation side effect is there none the less. It
is inherent to a digital signature with a chain of trust.

> "may" does not mean "it could possible be, so you'd better assume that

I am sorry, but I do not understand what you were saying here, perhaps you
could rephrase it?

could you please explain why you are reluctant to acknowledge the presence
of the non-repudiation side effect in the draft?

> >assure the secure use of a RSA public key that is not certified using

Handling the non-repudiation issue is secondary; adding the key management
requirements will strengthen the IPsec RSA signature spec considerably....

thx,
	George

---

From: Brian Weis <[email-masked]>
Date: Wed, 18 Aug 2004 13:08:52 -0700

Hi George,

>I am sorry, but I do not understand what you were saying here, perhaps you
Sorry for the confusion. I was trying to make the point that when RFC 
2408 says "may", it is simply acknowledging that in some uses, the 
signature payload type could be used for non-repudiation purposes. But 
RFC 2408 simply defines a payload type. It cannot know the usage context 
of a signature payload, and thus can't make a statement on whether there 
is or is not non-repudiation for a particular usage.

>of the non-repudiation side effect in the draft?
Because I do not agree that there is a non-repudiation side affect to 
using public keys as an ICV on an IPsec data packet. I'm afraid we're 
just going to have to disagree on this point.

Thanks,
Brian

---

From: canetti <[email-masked]>
Date: Thu, 19 Aug 2004 00:13:02 -0400 (EDT)

George,

On Wed, 18 Aug 2004, George Gross wrote:

...

> caveat is that YMMV wrt/ non-repudiation in the legal sense.

There is a difference between an "uncertified" public key and an
"unauthenticated" one.

For instance, if you and I already share an authenticated channel, and you
send to me a public key on this channel, then I know that this key comes
from you - thus i can use if for further authentication. But I cannot prove
to a third party, that the key came from you - since you never
certified it. (in other words, as far as the third party is concerned,
i could have generated this public key myself and am falsely
claiming that it came from you.)

Now, It is up to the key management algorithm whether to sign the RSA public
key to be used in ESP-RSA, or to authenticate it without signing
(eg, by MACing it using a key derived fom the session key).

It is indeed interesting to look at existing key management protocols and
see whether they explicitly sign the SA exchange, or do they just MAC the
SA exchange.

But, I must say that this concern of "involuntary non-repudiation" seems
like a secondary issue to me - I find it hard to believed that IP leyer
packet signatures, that are not managed directly by any application or user,
can be really used in court to prove non-repudiation.

> assure the secure use of a RSA public key that is not certified using

I'm not sure what you refer to. The ESP-RSA key will be simply sent to
the group member by the GCKS, together with the rest of the SA information
for that session. no?

Best,

Ran

---

From: George Gross <[email-masked]>
Date: Thu, 19 Aug 2004 09:16:33 -0400 (EDT)

Hi Ran and Brian,

> claiming that it came from you.)

In your example, the signature private key is known to two parties, so of
course all bets are off wrt/ non-repudiation. As for authentication, if
the GC/KS downloads the signature private key into a GM, there still has
to be a trusted mechanism for the GC/KS, acting as the group's TTP, to
tell the group membership: The public key "XYZ" belongs to the identity
known as Group Speaker George. Otherwise, a rogue Group Speaker could
assert public key "JKL" belongs to Group Speaker George ;o) To publish the
public key's binding, the GC/KS would sign a message containing the RSA
public key and multicast it to the group, right?

> (eg, by MACing it using a key derived fom the session key).

==> So your definition of public key "certification", as opposed to public
key "authentication", requires that the Group Speaker demonstrate its
exclusive POP for its signature private key to the GC/KS and the GC/KS
sign an object (i.e. a certifying message) that it witnessed that POP?

> see whether they explicitly sign the SA exchange, or do they just MAC the

Given exclusive POP of the private key is the critical litmus test, I now
better understand Brian's statement in an earlier e-mail:

bew> Because I do not agree that there is a non-repudiation side affect to
bew> using public keys as an ICV on an IPsec data packet. I'm afraid we're
bew> just going to have to disagree on this point.

I see why there isn't a non-repudiation side effect for the GDOI/ISAKMP
example that we were talking about, as in the GDOI/ISAKMP scenario the
GC/KS knows and downloads the Group Speaker's private key. So in summary,
the non-repudiation side effect is dependent on the key management
protocol providing the chain of trust AND having a proof of possession
evidence for the Group Speaker's self-generated signature private key
(which is never shared with the GC/KS or any other party).

As a thought experiment, I sketched out on the back of an envelope how
GSAKMP could add a non-repudiation service using the IPsec RSA signature
facility.  I concluded it was technically possible to piggyback new
payloads on the existing exchanges to achieve this. Note that I am not
proposing this, it was for illustrative purposes only ;o)

My point is that IPsec RSA signature could support a full-fledged
non-repudiation service. However, it is something that the key management
protocol has to explicitly add features to support.

> can be really used in court to prove non-repudiation.

In my GSAKMP IPsec mapping draft, there is an attribute certificate
payload that delegates an application endpoint's signature authority to
the IP layer GSAKMP subsystem. Although intended for delegating GSAKMP
message signatures, it would be feasible to add another authorization flag
in that attribute cert for delegating the source origin authentication
signature. Of course, this delegation is clearly voluntary on the part of
the application issuing the attribute cert.

The question whether that IP layer signature also supports non-repudiation
boils down to the group key management protocol's design goals, as
discussed above.

I would like to suggest that the IPsec RSA signatures draft add the
following language wrt/ the above non-repudiation topic in its Security
Considerations section first paragraph's list of protections:

" o Non-repudiation. The key management protocol MAY provide a
non-repudiation service for the signatures generated by the RSA
private/public key pair. The mechanisms that support that service are
outside the scope of this specification."

hth,

	George

<snip>

---

From: Brian Weis <[email-masked]>
Date: Thu, 19 Aug 2004 17:04:05 -0700

Hi George,

George Gross wrote:

>course all bets are off wrt/ non-repudiation. 
>
No, only one party has the private key. Let me re-state Ran's example in 
hopes of making it clearer.

1. A sends B public key P1 in an authenticated channel.
2. A creates a message with content that is offensive to B and signs it 
with public key P1.
3. B is angry but cannot prove to a 3rd party that A sent the offensive 
message, because A never presented a certificate proving that its 
identity is associated with public key P1.
4. In fact, A can can delete the key pair and claim that B created the 
key pair and the message signed by it. This possibility of repudiation 
is what ruins the prospect of B claiming non-repudiation.

Now you may argue that B can claim non-repudiation because the channel 
was authenticated. Perhaps the authenticated channel has a 
non-repudiation property, perhaps not. To know, you'd have to apply the 
same logic to that authentication method for that channel. Still, we 
cannot say that either B or a 3rd party can prove non-repudiation on the 
packet A sent to B.

[snip]

>outside the scope of this specification."
This suggestion caused me to look at  RFC 2552/BCP 72 "Guidelines for 
Writing RFC Text on Security Considerations" again. It has two 
interesting write-ups on non-repudiation, sections 2.2 and 4.3. After 
reading this text I really feel that the difficulties with 
non-repudiation are so great that it is inappropriate to claim it as a 
protection in the Security Considerations of this draft, even supposing 
that it were to be performed by key management.

Thanks,
Brian

---

From: canetti <[email-masked]>
Date: Thu, 19 Aug 2004 23:36:50 -0400 (EDT)

George,

I agree with most of what you say below. One clarification though:
In my example below only the party that generated the keys ("you") in
the example knows the the private signing key. Similarly, in the group
setting with a GC/KS, only the sender knows the secret signing key.
The sender sends the public verification key to the GC/KS over an
authenticated unicast channel, and the GC/KS sends this key to each
member, again over an authenticated unicast channel.

The point is, again, that authentication is different than
non-repudiation. For authentication, I only need to know for myself that
the message I receive is authentic. For non-repudiation, I haveto be able
to prove this fact to a third party.

Ran

PS: Again, I think it will be useful if much of this discussion made it to
the draft for clarification.