Subject: [MSEC] Reply to Re: Last Call: 'The Use of RSA Signatures within ESP and AH' to Proposed Standard

From: Brian Weis <[email-masked]>
Date: Fri, 03 Jun 2005 17:00:36 -0700

Hi Ian,

This email is a response to Last Call comments you made some time
ago regarding an MSEC WG draft. Unfortunately your comments did not
actually make it onto the WG mailing list.  Sam Hartman recently
forwarded them to us.

We are now at draft-ietf-msec-ipsec-signatures-05.txt, and I believe
we have resolved or answered the issues you raise below. However,
I've also answered them directly below inline between snippets of
your original comments.

 >1. It is unclear what is specified
 >----------------------------------
 >
 >The whole point of the RSA-ESP/EH specification is to unambiguously
 >tie the concepts and protocol elements specified in RSA (RFC3447) to
 >those specified in ESP (currently envisaged by the RSA-ESP/EH draft as
 >draft-ietf-ipsec-esp-v3-09.txt).
 >
 >It appears that section 2.0 `Algorithm and Mode' of
 >draft-ietf-msec-ipsec-signatures-03.txt is intended to do this.
 >
 >It should explicitly state, in the terminology of
 >draft-ietf-ipsec-esp-v3 and RFC3447:
 >
 >* Which value in RFC3447 corresponds to the byte string whose ICV
 >  is to be calculated (this byte stream is defined by the ESP and
 >  AH specifications).
 >
 >* Whether padding is required (see eg draft-ietf-ipsec-esp-v3-09
 >  3.3.2.1 final paragraph).  (It seems unlikely that a sensible RSA
 >  embedding in IPSEC would require padding.)
 >
 >* Which value from RFC3447 corresponds to the ICV.
 >
 >* What the length of the ICV is (eg draft-ietf-ipsec-esp-v3-09 2.8)
 >  or if it varies per packet, how the length is encoded.
 >
 >etc.

The above specification elements  were indeed missing, and have been 
added to Section 2.0.

 >2. Specified algorithm is not best current cryptographic practice
 >-----------------------------------------------------------------
 >
 >Guessing the answers to the questions above, it seems that what is
 >specified is some kind of ad-hoc variation on RSA OAEP.  OAEP is an
 >_encryption_ sheme, intended to provide _confidentiality_ and is
 >completely inappropriate as an integrity mechanism.

This was indeed a horrible mistake. The original intent was to do
what IKEv1 specified for signatures, especially given that IKEv2
does little better in specifying the padding method. IKEv1 specifies
an _encryption_ PKCS#1.5 padding, with the rationale of not needing
to encode the hash algorithm in the signature as required by
RSASSA-PKCS1-v1_5 in RFC 3447.

The draft you reviewed followed suit, because the expectation is that it
will be deployed in the same products containing IKE, and there would
be considerable implementation value to performing the same operations.
However, awareness of the IKEv2 padding under-specification has now
been raised in the IPsec community, and it is not clear what kinds
of padding will be used with IKEv2. Therefore it is no longer clear
that there is any value at all to the IKEv1 scheme.  As a result,
version 05 of the IPsec signatures draft now specifies the integrity
padding methods as defined in RFC 3447. This matches your recommendation
of using an integrity mechanism.

 >3. Best cryptographic practice is to use PSS (RFC3447's RSASSA-PSS)
 >-------------------------------------------------------------------
 >
 >RSA PSS (RFC3447's RSASSA-PSS) is widely acknowledged in the
 >cryptographic community to be significantly superior to earlier RSA
 >padding schemes.  There is no good reason presented in
 >draft-ietf-msec-ipsec-signatures-03 for not using it, and there
 >probably is no good reason not to use it.

Although PSS is acknowledged to be superior to PKCS#1.5, it has the
difficulties that 1) it is not as widely deployed as PKCS#1.5, and
2) it has not been explicitly cleared for use by the IETF by the
PSS patent holder.  Therefore, it is not reasonable to require the use
of PSS. PSS has been included in the draft as a choice, but not as a MUST.

If you have any further comments or questions on the draft, please
send them directly to [email-masked].

Thanks,
Brian
-- 
Brian Weis
Advanced Security Development, Security Technology Group, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Brian Weis <[email-masked]>
Date: Mon, 13 Jun 2005 14:27:10 -0700

Ian Jackson had the attached comments on 
draft-ietf-msec-ipsec-signatures-05.txt. He was not able to post them to 
the list directly.

Brian

-- 
Brian Weis
Advanced Security Development, Security Technology Group, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]
Subject: Re: Reply to Re: Last Call: 'The Use of RSA Signatures within ESP and AH' to Proposed Standard
From: Ian Jackson <[email-masked]>
Date: Mon, 6 Jun 2005 12:37:38 +0100
To: Brian Weis, [email-masked], [email-masked]

>> I've also answered them directly below inline between snippets of

Thanks.  (I have reformatted your mail when quoting it, as it had
serious wrap damage.  You need to get better email software.)

I've reviewed the -05 draft and I think it's barely adequate; there
are things that really should to be improved if it's not too late in
the process.  I'm still disappointed by the lack of quality and
precision in draft-05's s2.0, which is the heart of the specification.

>>> >tie the concepts and protocol elements specified in RSA (RFC3447)
>>> >to those specified in ESP (currently envisaged by the RSA-ESP/EH
>>> >draft as draft-ietf-ipsec-esp-v3-09.txt).

...

>> The above specification elements  were indeed missing,
>> and have been added to Section 2.0.

The new language in section 2 is now just about adequate.  A really
close reading by an honest reader leaves no other interpretation but
the one presumably intended.  A careless or disingenuous reader (for
example, a busy implementor, and then later the same implementor
having implemented something different) might manage to come up with a
deviant reading.  It's still very oblique.

My experience with documents of this kind - which refer to parts of
other protocols which have different terminologies and backgrounds -
is that it is best to be explicit, and to explicitly and carefully use
the terminology from the two documents being joined.

Specifically, in this case, draft-05 s2.0 says `The authenticated
portion of the AH or ESP packet is given to the signature generation
function'.  The term `signature generation function' is not defined by
PKCS#1; and `given to' is somewhat vague.  The RSA-AH document should
explicitly state the name given to the corresponding value in PKCS#1,
ie `M'.  It should say something like `the authenticated portion of
the AH or ESP packet ([AH] 3.3.3) is used as the message M and passed
to the signature generation operation ([RSA] 8.1.1, 8.2.1).

draft-05 s2.0 doesn't explicitly say what's done with the signature;
it doesn't talk about the `ICV' (RFC2402 2.6) - preferring its own
term `authenticator value' - and it doesn't mention S (PKCS#1 8.1.1,
8.2.1) let alone state that S and the ICV are identical.

draft-05 s2.0 does say that the ICV (which it calls the `authenticator
value') `is equal to the size of the RSA modulus' which is at least
somewhat helpful but strictly speaking incorrect - it is in fact equal
_in size_ to the RSA modulus; the ICV value is not equal to the
modulus size.  This is perhaps less explicit than RFC2402's
requirement that `The authentication algorithm specification MUST
specify the length of the ICV' since it's not clear whether it refers
to a bit length or byte length or should perhaps even be rounded up.

RFC2402 also says `The authentication algorithm specification MUST
specify [...] the comparison rules and processing steps for
validation' which draft-05 does not.

>> As a result, version 05 of the IPsec signatures draft now specifies
>> the integrity padding methods as defined in RFC 3447. This matches
>> your recommendation of using an integrity mechanism.

So I see.  This is good.

>> 2) it has not been explicitly cleared for use by the IETF by the PSS
>> patent holder.  Therefore, it is not reasonable to require the use

Lack of wide deployment is not a reason not to specify a superior
algorithm in a new standard.  The PSS patent isn't really a problem,
is it ?  The University of California have said they'll licence it
appropriately if it is made an IEEE standard - can't we get a similar
statement for the IETF ?

>> send them directly to [email-masked].

I did so with my previous comments, but you say that the WG didn't
receive them.  I note that the domain name in your own CC was
`multicast.org' rather than `securemulticast.org'.  I've CC'd both.

Ian.

Re: Reply to Re: Last Call: 'The Use of RSA Signatures within ESP and AH' to Proposed Standard.eml
	
Content-Type:
	message/rfc822

---

From: Brian Weis <[email-masked]>
Date: Mon, 13 Jun 2005 14:35:54 -0700

Hi Ian,

> the terminology from the two documents being joined.

Thanks for pointing this  out ... it's good advice. I have some
suggested replacement text below to map the two terminologies.
Comments on the replacement text are welcome.

> 8.2.1) let alone state that S and the ICV are identical.

The following text addresses comments in the previous two paragraphs.

"Digital signature generation is performed as described in [RSA, Section 
8.1.1]
(RSASSA-PSS) and [RSA, Section 8.2.1](RSASSA-PKCS1-v1_5). The authenticated
portion of the AH or ESP packet ([AH, Section 3.3.3], [ESP, Section 
3.3.2]) is
used as the message M, which is passed to the signature generation function.
The signer's RSA private key is passed as K. Summarizing, the signature
generation process computes a SHA-1 hash of the authenticated packet bytes,
signs the SHA-1 hash using the private key, and encodes the result with the
specified RSA encoding type. This process results in a value S, which is 
known
as the ICV in AH and ESP."

> to a bit length or byte length or should perhaps even be rounded up.

This comment regarding 'bit length or byte length' caused me re-visit
the topic of ESP and AH padding requirements. I believe the sentence
in -05 stating "No ICV Padding bits are necessary" is incorrect.
There's also an issue in that ESP does not state how to handle an
ICV that is not a multiple of 8 bits, which can happen with an RSA
modulus that is not a multiple of 8 bits, because ESP does not
specify the use of explicit padding bits. I believe the following
two paragraphs thoroughly define ESP and AH padding.

"When specified for ESP, the ICV is equal in size to the RSA modulus, unless
the RSA modulus is not a multiple of 8 bits. In this case, the ICV MUST be
prepended with between 1 and 7 bits set to zero such that the ICV is a
multiple of 8 bits. This specification matches the output S [RSA, Section
8.1.1] (RSASSA-PSS) and [RSA, Section 8.2.1](RSASSA-PKCS1-v1_5) when the RSA
modulus is not a multiple of 8 bits. No implicit ESP ICV Padding bits are
necessary.

When specified for AH, the ICV is equal in size of the RSA modulus, 
unless the
RSA modulus is not a multiple of 32 bits (IPv4) or 64 bits (IPv6) [AH, 
Section
2.6]. In this case, explicit ICV Padding bits are necessary to create a
suitably sized ICV [AH, Section 3.3.3.2.1]."

Note that there is no need to specify the format of the AH padding bits.
The referenced section declares that "The content of the padding field is
arbitrarily selected by the sender."

> validation' which draft-05 does not.

The last paragraph of section 2.0 (appearing at the top of page 4
of -05) specifies comparison rules and validating steps.
However, in the spirit of precision I believe the following replacement
paragraph is better:

"Digital signature verification is performed as described in [RSA, Section
8.1.2] (RSASSA-PSS) and [RSA, Section 8.2.2](RSASSA-PKCS1-v1_5). Upon 
receipt,
the ICV is passed to the verification function as S. The authenticated 
portion
of the AH or ESP packet is used as the message M, and the RSA public key is
passed as (n, e). In summary, the verification function computes a SHA-1 
hash
of the authenticated packet bytes, decrypts the SHA-1 hash in the ICV, and
validates that the appropriate encoding was applied and was correct. The two
SHA-1 hashes are compared, and if they are identical the validation is
successful."

> appropriately if it is made an IEEE standard - can't we get a similar

They've been asked to do this, but to date have not submitted any statement.

Thanks,
Brian