Pasi Eronen and Valtteri Niemi write: Section 7 --------- It seems that AH_RSA_Sig does not integrate very well with the standard IPsec architecture, and it may well be that the alternative recently discussed on SEND mailing list (drop IPsec, and integrate the cryptographic parts to ND messages) could a be better choice. If we stick with AH, at least the following issues need to be addressed. However, especially the replay protection issue (below) seems to be rather difficult to fix in an elegent way. o Section 7.1.2 (technical/editorial): Any particular reason why the document refers to PKCS#1 v1.5 (almost 10 years old) instead of PKCS#1 v2.1 (2002)? The newer version includes the old 1.5 algorithms, but has substantial editorial improvements (also, 1.5 didn't include SHA-1 OIDs). PKCS#1 v2.1 is also published as RFC 3447 (informational). o Section 7.1.2 (technical): This does not specify the hash algorithm for the RSA signature. (The hash algorithm that was used can be deduced from the PKCS1.5 signature, but still SEND should specify what the sender should select). Might something like "The signature value is computed with the RSASSA-PKCS1-v1_5 algorithm and SHA-1 hash as defined in [PKCSv21]." be better? o Section 7.1.2 (technical): If the signature is calculated "over the the [sic] whole packet as defined by the usual AH rules [3]", the Timestamp and Key Information fields won't get included in the calculation (the usual AH rules say that the whole Authentication Data part is set to zero for this calculation). o Section 7.1.2 (technical): AH requires that the Authentication Data field must be multiple of 32 bits (for IPv4) or 64 bits (IPv6). This means that in some cases, additional padding must be added to the end of the Authentication Data field. While the draft says that "The length of this field [Digital Signature] is determined by the PKCS #1 encoding.", the PKCS#1 RSA signature does not actually include a length field. Adding a new length field to tell where the signature value ends and padding starts would probably be the easiest solution. It's not absolutely necessary, though, since the signature value has always the same length as the RSA modulus (in its "raw" form -- which can be different than the DER encoding of RSAPublicKey.modulus field). Another complication related to this is that the length of the signature field must be known before signing. o Section 7.2 (technical) This section actually proposes quite a radical change to IPsec processing! The destination-agnostic SAs are indeed covered by the (uncontroversial) changes in ESPv3/AHv3. However, selecting an inbound SA based on ICMPv6 type code is not. The SPD selectors indeed contain a field for port number where this could be stored. However, in normal IPsec processing, the SPD is checked only after the packet has been authenticated -- so it can't be used to select an SA for inbound packets (the example policy entries in Sections 8.4 and 9.5 also assume that SPD is consulted before selecting SA). But using the ICMPv6 type for selecting inbound SA would also be some sort of protocol layering violation.... Fixing this might be possible rather easily. One possible way to refactor this would be the following: - Always create exactly two special inbound SAs (with two different special SPIs), one for plain AH_RSA_Sig and other one for AH_RSA_Sig+CGA verification (hosts which don't support CGA can treat these two identically; sender can select which to use). This should remove the need to have a separate CGA flag. - Move most of the fields from the inbound SAs to inbound SPD entries (except CGA flag). ----------- Jari Arkko responds: > It seems that AH_RSA_Sig does not integrate very well with the > standard IPsec architecture, and it may well be that the alternative > recently discussed on SEND mailing list (drop IPsec, and integrate the > cryptographic parts to ND messages) could a be better choice. If we No argument from me ;-) > stick with AH, at least the following issues need to be addressed. > However, especially the replay protection issue (below) seems > to be rather difficult to fix in an elegent way. > > o Section 7.1.2 (technical/editorial): Any particular reason why > the document refers to PKCS#1 v1.5 (almost 10 years old) > instead of PKCS#1 v2.1 (2002)? The newer version includes the old > 1.5 algorithms, but has substantial editorial improvements (also, > 1.5 didn't include SHA-1 OIDs). PKCS#1 v2.1 is also published as RFC > 3447 (informational). This should be fixed. There was no particular reason for the old reference, except maybe that the old reference was readily available in my xml2rfc bibliography ;-( > o Section 7.1.2 (technical): This does not specify the hash > algorithm for the RSA signature. (The hash algorithm that was used > can be deduced from the PKCS1.5 signature, but still SEND should > specify what the sender should select). > > Might something like "The signature value is computed with the > RSASSA-PKCS1-v1_5 algorithm and SHA-1 hash as defined in > [PKCSv21]." be better? Ok. > o Section 7.1.2 (technical): If the signature is calculated "over > the the [sic] whole packet as defined by the usual AH rules [3]", > the Timestamp and Key Information fields won't get included in the > calculation (the usual AH rules say that the whole Authentication > Data part is set to zero for this calculation). Oops. Another sign of not a perfect match for AH. > o Section 7.1.2 (technical): AH requires that the Authentication Data > field must be multiple of 32 bits (for IPv4) or 64 bits (IPv6). > This means that in some cases, additional padding must be added to > the end of the Authentication Data field. > > While the draft says that "The length of this field [Digital > Signature] is determined by the PKCS #1 encoding.", the PKCS#1 RSA > signature does not actually include a length field. Adding a new > length field to tell where the signature value ends and padding > starts would probably be the easiest solution. It's not absolutely > necessary, though, since the signature value has always the same > length as the RSA modulus (in its "raw" form -- which can be > different than the DER encoding of RSAPublicKey.modulus field). > > Another complication related to this is that the length of the > signature field must be known before signing. Yes. I would add a new length field, but I agree that its a bit complicated. ----------- Jari Arkko: Note from your editor: The IPsec-specific problems do not need to be addressed now. Knowing the length field before the signature has been constructed is no longer a problem either, given that the Signature option itself is not included in the calculation. ----------- ----------- ----------- ----------- ----------- ----------- -----------