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

From: <[email-masked]>
Date: Wed, 18 Aug 2004 10:23:25 -0400

I agree, non-repudiation should be an (possibly negotiable)option
for the parties involved in the secure communication. It should 
not be mandated. I guess that is why IKE has shy'd away from 
mandating signatures with certificates.

Also, Ran brings up a good argument: that signatures by themselves
do not imply non-repudiation. It is in the proof of possession of
the keys that we can imply non-repudiation.

But at the same time, the issue of non-repudiation raised by George
brings about few interesting questions:

	* How do we provide an option (not mandated) in IPsec protocols
	  to provide non-repudiation? I had suggested a way using 
	  transitive-non-repudiation using the non-repudiated optional
	  IKE communication. Something to convey to the IPsec working 
	  group. Not an MSEC WG item.

	* We are saying that this I-D talks about just usage of signatures
	  not how keys used in the signatures are gotten/certified. But do
	  we have a precedent in IETF, where signatures are used without
	  certificates? Is there a standard/standards track document which
	  conveys how signatures can optionally be used without certificates?
	  Though not necessary, digital signatures do generally imply 
	  certificates.

	* Though this I-D need not be worried about certificates, MSEC group 
	  has to be mindful of this issue. What good be standardizing usage
	  of signatures in MSEC, without telling how those signatures shall be
	  gotten, from what keys, how those keys shall be gotten/certified?
	  These are all implementation issues. And in IETF, at least,
	  implementation is an integral part of the standardization process.

	* Do we want to make it a WG action item: signatures or rather public 
	  keys without certificates an option in MSEC key management protocols?

Just my thoughts on this issue.

Atul

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext canetti
> Sent: Wednesday, August 18, 2004 1:08 AM
> To: Brian Weis
> Cc: [email-masked]
> Subject: Re: [MSEC] Why the rsa-signatures draft doesn't 
> explicitly deal
> withPKI issues
> 
> 
> 
> 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
> 
> 
> On Tue, 17 Aug 2004, Brian Weis wrote:
> 
> > 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
> >
> _______________________________________________
> msec mailing list
> [email-masked]
> http://six.pairlist.net/mailman/listinfo/msec
> 
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec