Subject: Re: SEND protocol document review

From: Jari Arkko <[email-masked]>
Date: Wed, 09 Jul 2003 13:38:16 +0300

Hello Pasi and Valtteri,

Returning back to your review comments. Many thanks for
your valuable comments! Discussion inline below:

> Other comments follow:
> 
> o  Section 4: Good text, but perhaps would be even clearer if Router
>    Discovery would be mentioned before Address Autoconfiguration and

Ok.

>    Redirect. Also, the list of destination address rules is perhaps in
>    the wrong place.

Yes. The thing is, it is quite important information if one uses
IPsec. However, I have proposed the use of ND options which would
essentially make this list unnecessary. I'm hoping that would fix
this issue...

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

Ok.

> 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

Ok.

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

I don't know. Perhaps Pekka and James could say something about this.

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

Right. I think Pekka who wrote this part of the text is aware of
this problem, and its being discussed.

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

I agree.

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

Yes.

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

Ah yes. Hmm... I guess we just wanted to stay away from DNs altogether.
But maybe that is not possible. Pekka?

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

Agreed. I believe some off-list discussions were going around on this
subject, with the PKIX folks.

> 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

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.

> o  Section 7.1.3 (technical): Is it possible to configure more 
>    than one trusted root?

This would make sense.

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

Hmm.... perhaps minbits should be kept as a CGA-specific policy,
i.e. apply only to the key which is used in the CGA generation.

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

I'm not sure how this would work. We don't necessarily know the
peer's key. Can you clarify?

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

Right. This particular case would work better with ND options, because
you can take a look at the nonce and be satisfied even if the timestamp
is wrong. But we still do have an issue of what to do with unsolicited
advertisements!

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

Yep.

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

Actually, the first option sounds pretty good. The only downside
is that signature verification has to occur before replay
protection, which adds to the DoS issues that I already worry
a bit in SEND.

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

But wait. The inbound SA is selected purely by the SPI. After
decryption it is matched with the SA's selectors. There's nothing
controversial about this part. The only question is if SPDs/selectors
can use ICMPv6 type codes. Based on recent discussion in IPsec WG,
this will likely happen.

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

Ah yes now I see what you are getting at. Yes, separate SPIs
appear to be needed.

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

They are currently included because they require no configuration.
But you are right that they might not offer any protection, at
least no as currently specified.

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

This needs to be reformulated accordingly.

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

Good question. This isn't currently discussed, I think. But isn't
this rather obvious? nodes that have both certs and cgas can interwork
with nodes that use only certs. And it also works in the reverse
direction, assuming we can set a policy which requires at least one
of cga or cert to be used.

> 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?

To prevent the non-SEND nodes (in some cases) using the SEND node's
address. I believe this is discussed in the security considerations.

> 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?

I think I wrote that down somewhere, but now I can't find it.
I think the intention is to allow the SEND-capability to be per
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.

Yes. I believe this is an open issue which has been discussed
before. Solutions for this include two link-local prefixes, or
switching to draft-arkko-send-ndopt-00.txt.

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

Yes. Thanks.

--Jari

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