Subject: SEND protocol document review

From: <[email-masked]>
Date: Thu, 19 Jun 2003 13:28:42 +0300

Hi,

Please find below our review of draft-ietf-send-ipsec-01.

Best regards,

Pasi Eronen &
Valtteri Niemi

---------------------------------------------------------------------------

Overall, our biggest complaint about this document is that it seems the
use of certificates instead of CGAs for Neighbor Discovery (not Router
Discovery) is not really thought out yet.  We believe the document would
probably be significantly easier to understand and analyze if the CGA
case was described separately from the non-CGA case. This could mean
splitting to two separate documents, or at least to separate sections
within one document (consider such a split especially for sections 4
and 8).

Other comments follow:

o  Section 4: Good text, but perhaps would be even clearer if Router
   Discovery would be mentioned before Address Autoconfiguration and
   Redirect. Also, the list of destination address rules is perhaps in
   the wrong place.

Section 6
---------

This section might be easier to read if it would be split to two
parts: one describing what sort of certificates are used, and a 
second section specifying how the certificates are transported 
over ICMPv6.

The certificate transport is relatively straight-forward, but the
description of certificate chains could benefit from some
clarifications and examples showing at least one valid certificate
chain. Also, if certificates are used for both RD and non-CGA ND, any
differences should be described (e.g., in the ND case, would a PKC
chain ending in an iPAddress subjectAltName be sufficient, or do we
also need the AC?)

Especially the selection of Attribute Authorities (valid AC issuers)
seems a bit strange.  The "trusted root" refers to valid PKC issuers,
right? And then all CAs (PKC issuers) in the PKC path (from the trust
anchor to the router's PKC) are also considered AAs.  Unfortunately,
RFC 3281 (section 4.5) explicitly forbids this!  If this is done 
anyway, it should be at least well explained and justified.

Another aspect that requires clarification is the requirements placed
on the PKC chain.  At the minimum, the spec should say what
requirements are placed on subjectName, subjectAltName, and
keyUsage.  Preferably the spec should also give some recommendations
for interoperability (see draft-ietf-ipsec-pki-profile-02 for
example).  Also, when specifying this, the SEND spec should probably
refer to the PKIX profile (RFC 3280) rather than X.509 itself.

Several other points related to this section:

o  Section 6.3 (editorial): In PKIX-speak, the correct
   term would probably be "trust anchor", not "trusted root".

o  Sections 6.3 and 6.6 (technical): Presumably, the "trusted root"
   should contain the issuer of the first certificate in the chain?
   But for X.509 certs, that's a Distinguished Name, not FQDN.  So,
   should the "trusted root" option contain a DER-encoded Issuer DN
   instead of FQDN?
 
   Using AltSubjectName (correct spelling is subjectAltName, BTW)
   seems to make it more difficult for the router to decide which
   certificate to send, since its own certificate doesn't necessarily
   have the CA's dNSName (though it may be included in issuerAltName
   extension).

o  Section 6.5.1: The definition of the Holder field is a bit vague,
   and goes against the recommendations of RFC3281 (if this is
   intentional, at least the reasons for doing so should be
   documented).  Our interpretation is that RFC3281, in this particular
   scenario would strongly recommend using the baseCertificateID
   syntax (instead of entityName or objectDigestInfo).

   Also, even if entityName or objectDigestInfo is used, RFC3281
   recommends using only one of them, and recommends using only one
   entityName (not multiple), and says that if entityName is used, it
   MUST match the PKC certificate.

o  Section 6.5.1: If objectDigestInfo is used with
   digestedObjectType=publicKey, RFC3281 already specifies how
   objectDigest field must be calculated (section 7.3).
   
o  Section 6.5.1: Normative reference to an expired Internet-Draft
   (for the AuthorizedSubnetPrefix) probably isn't a good idea.  Since
   it seems that the pkix-x509-ipaddr-as-extn draft is dead, either
   the relevant definitions should be copied here, or documented in a
   new, separate internet draft.

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.1.3 (technical): Is it possible to configure more 
   than one trusted root?

o  Section 7.1.3 (technical): Definition of "minbits" (sort of)
   assumes that all intermediate certificates are also signed with
   RSA. In general, this doesn't have to be true: a certificate for
   peer's RSA key could be signed with elliptic curve DSA or  
   something else for which the "minbits" doesn't make sense.

   Also, "minbits" is just one example of a policy specifying what
   sort of certificate chains are acceptable and what are not.  For
   instance, we could require revocation checks (CRL lookup, or OCSP).
   Maybe these shouldn't be in the SA at all, so perhaps
   "minbits" could be redefined to refer just to the peer key? 
   (If it's needed at all)

o  Sections 7.1.4 and 7.1.2 (technical)

   The document is less than clear when timestamp anti-replay
   protection should be enabled for inbound security associations, and
   how nodes without accurate clocks should work. Note that in normal
   AH, only checking sequence numbers is optional--generating them
   is not.  In AH_RSA_Sig, we can have a situation where the sender
   has bad clock and generates completely bogus timestamps, but the
   receiver would like to check them -- and has no way of signalling
   this to the sender.

   For instance, if the timestamp checking is enabled for all inbound
   Neighbor Advertisement messages, then all messages from nodes with
   bad clocks are dropped. But replays of solicited advertisements
   could be prevented by nonces alone...

   (One alternative would be that the sender of the solicited NA
   copies the timestamp value from the solicitation, just like nonce,
   but this sounds like an ugly protocol layering violation to me).

   A similar problem applies to Neighbor Solicitations. If timestamp
   checking is enabled for all inbound NSs, nodes with bad clocks
   can't get our address. If we don't check timestamps, replays are
   possible (and as described in psreq-03 section 4.1.1, there are
   cases when a node may create neighbor cache entries based on
   Solicitation messages).  So, a sensible rule might be that "in case
   of invalid timestamp, still respond to the message, but don't
   create a neighbor cache entry", right? (Again, this seems to 
   break protocol layering)

   One possible solution to these layering violations (between
   AH_RSA_Sig and ICMPv6) would be to move the timestamp (and thus all
   replay protection) to the ICMPv6 layer, by adding a new option
   similar to Nonce. Or move the nonce to AH layer (but we can't see a
   simple way to do this).

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).

Sections 9-11
-------------

o  Section 9.2.2 (technical/editorial): When Router Advertisements
   protected only with CGA (but not trusted root) are useful?
   If they are, document reasons...

o  Section 9.3.2 (editorial): These requirements duplicate some of
   the requirements already described in RFC2461 (section 8.1).
   E.g. RFC2461 already says that unspecified source address is not
   allowed, and must match the current routing table.

o  Section 10: What about co-existence of nodes using CGA and those 
   not using CGA?

o  Section 10.1 (editorial/technical): If SEND nodes don't try do
   detect if the same address is used by a non-SEND node, why DAD
   Neighbor Solicitations are sent to the normal solicited-node
   multicast address, too?

o  Section 10.1 (technical): The spec says that "Hosts configured for
   SEND MUST use SEND for all of their addresses, including link local
   addresses.". Are hosts allowed to use SEND on one link, and not 
   use SEND on some other link?

o  Section 10.1 (technical): "Secure Router and Neighbor
   Advertisements MUST use a source address that satisfies the
   security properties outlined in Section 9.  Unless this address is
   link-local, it MUST belong to one of the advertised secure
   prefixes.  Similarly, source addresses for insecure advertisements
   MUST belong to one of the advertised insecure prefixes, unless the
   address is link-local."

   This changes RFC261 requirements (the source address of Router
   Advertisements is always a link-local address). If this is
   intentional, document justifications.

o  Section 11 (editorial): In phrase "Signatures related to the use
   of the AH_RSA_Sig transform MAY be precomputed for Multicast
   Neighbor and Router Advertisements.", perhaps "..precomputed for
   unsolicited (multicast) Neighbor and Router..." would be clearer.

---------------------------------------------------------------------------

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Thu, 19 Jun 2003 14:35:35 +0300

Thank you Pasi and Valtteri for your in-depth review!

> Discovery) is not really thought out yet.  We believe the document would

I agree that ND cert usage is less baked than the rest of the spec.

> within one document (consider such a split especially for sections 4

The CGA and Signature options that I outlined in draft-send-ndopt.txt
might help the situation as well.

More later,

--Jari