Subject: Comments and questions on draft-ietf-send-ipsec-01

From: "Tuomas Aura" <[email-masked]>
Date: Sat, 14 Jun 2003 17:39:03 -0700

Here are a few comments and questions on 
draft-ietf-send-ipsec-01. 
Tuomas

*1*
Section 3, first bullet (NUD)

The text of the first bullet suggests that there 
are attacks against NUD where the soliciting node 
incorrectly deletes a neighbor cache entry. I don't 
understand how such an attack would be possible, 
except by blocking NAs. SEND definitely does not 
prevent such blocking attacks. 

The text appears to have been copied from 
draft-ietf-send-psreq-03.txt but that document does 
not explain any better how the attack is supposed 
to work. The only attack against NUD that uses 
spoofed NAs is one where the attacker keeps the 
address alive (makes it appear reachable) after the 
address owner has, in fact, become unreachable.
Proposal: Either delete this bullet or acknowledge 
the shortcoming of SEND in this respect. Or if I am 
wrong and such an attack exists, it should be 
explained better. Section 13.2 (and Section 4.1.2 of 
draft-ietf-send-psreq-03.txt) may also need revising.

*2*
Section 6.2 (Component field)

If a router has multiple trust roots and a separate 
delegation chain for each root, it should be able to 
send unsolicited Delegation Chain Advertisements for 
all these chains. But the Component field in the 
advertisement is not sufficient to tell which 
certificate belongs to which chain. 

Proposal: Replace the 16-bit Component field with an 
8-bit Chain Number field and an 8-bit Component field.

*3*
Section 6.5 (Authorization chain)

As far as I can understand, the authorization 
certificate chain consists of a chain of PKCs + 
one AC. The AC is issued by the subject of the last 
PKC. This is non-standard usage of PKCs as they are 
effectively used for authorization rather than for 
identification. 

Standard usage would be to have no authorization 
chains but only a single AC issued directly by whoever 
issues them. The AC would specify the name of its 
holder. A separate PKC chain would then be used to 
resolve the name into a public key. There could be
another PKC chain for the issuer of the AC.

Obviously, the standard usage is unsatisfactory for 
SEND. I don't have any better solution to suggest 
than what is currently in the draft and I believe 
the authors are fully aware of the problem. Just 
thought I'd rant a bit about it.

*4*
Section 6.7, paragraph 2 (storing certificates)

The text says that hosts should store *all*

certificates retrieved in DCAs. This is vulnerable 
to DoS attacks.

Proposal: "Hosts SHOULD store certificate chains 
retrieved in Delegation Chain Discovery messages if 
they start from a root trusted by the host. The 
certificate chains SHOULD be verified before storing 
them. Hosts SHOULD NOLT store Delegation Chain 
Advertisements that do not form a chain starting 
from a trusted root."

*5*
Section 7.1.3 (minBits)

There is a conflict between the default 768-bit 
modulus specified here and the minimum 1024-bit 
modulus required in draft-ietf-send-cga-00. The 
reason for the 1024-bit minimum is not security but 
that it makes the implementation of CGA slightly 
easier if the key lengths start from 1024 bits. 

Proposal: Either change the default to 1024 bits 
here or delete the 1024-bit minimum in 
draft-ietf-send-cga-00. (I don't have any personal 
preference.) 

*6*
Section 7.1.3 (minSec)

There is a conflict between the minSec configuration 
parameter here and draft-ietf-send-cga-00, which 
requires the CGA verifier to ignore the value of Sec 
after CGA verification succeeds. IMO, minSec should 
always be zero because it is the owner (not the 
verifier) of a CGA address that should decide the 
strength of the protection the address owner needs. 
However, one can envision future extensions of the 
protocol that are beyond the scope of the current 
work but might benefit from having the minSec 
parameter in the SA.

Proposal: Add the following text: "This parameter is 
intended to facilitate future extensions and 
experimental work. The minSec value SHOULD always be 
set to zero." I have already softened the corresponding 
text in draft-ietf-send-cga-00 to match this.

*7*
Section 7.1.3 (CGA flag)

The inbound AH_RSA_Sig SA currently allows the 
following three combinations of authorization 
mechanisms: (i) trusted root authorization required, 
CGA authorization not verified; (ii) CGA authorization 
required, trusted root authorization not verified; 
(iii) both trusted root authorization and CGA 
authorization required. It is impossible to specify 
the following combination: (iv) either mechanism is 
ok, the second need not be verified if the first one 
succeeds. I think the missing combination would be 
useful for NS, NA and RS.

Proposal: Replace the "router authority" flag and the 
"CGA flag" with an "authorization mechanism" parameter 
that can get the above 4 values.

*8*
Section 7.1.4 (replay protection)

It is unnecessary to maintain a cache of the full 
messages received within the allowed Delta (1 hour). 
It is sufficient to store the latest timestamp 
received from each specific source address.

Proposal: Revise the text to reflect the above.

*9*
Section 8.4 (outbound SPD and SAD entries)

If the AH_RSA_Sig transform in either allows or 
requires the CGA authorization mechanism to be used, 
the own address in the Source Address field of the 
corresponding policy entry MUST be generated as 
specified in Section 4 of [27].

Proposal: Add the above sentence to section 8.4.

*10*
Section 8.2.2 (Target Address)

The receiver needs to check that the Target Address 
of the NA is the same address that was used when 
verifying the AH, i.e. the Target Address must be 
equal to the IP Source Address.  

Proposal: "The receiver MUST verify that the 
Target Address field in the received Neighbor 
Advertisement is equal to the IP Source Address 
of the same packet."

*11*
Sections 9.1-9.2 (Source link-layer address 
option in NS/RS)

If a router solicitation or neighbor solicitation 
does not contain the Source link-layer address 
option, there is no security reason for 
authenticating the solicitation. RFC 2461 says that 
the option SHOULD be present in the solicitations. 
Perhaps it is worth repeating here.

Proposal: Maybe add the following clarification to 
sections 9.1.1 and 9.2.1: 
"RFC 2461 specifies that the Source link-layer 
address option SHOULD be included in solicitations 
where the source address in not the unspecified 
address. Thus, the Source link-layer option SHOULD 
be included in all secure router/neighbor 
solicitations. Note that the solicitations MUST be 
protected with the AH-RSA_Sig transform regardless 
of whether the option is present or not."

*12*
Sections 9.2.1-9.2.2 (Source link-layer 
address option in RA)

A router advertisement contains the following two 
kinds of information: (i) the router's link-local IP 
address and other router parameters and (ii) the 
link-layer address corresponding to that link-local 
IP address. These two parts have different properties 
when it comes to authorization. The CGA authorization 
method protects only the IP-address-to-link-layer-address 
mapping but has no value in protecting the router 
IP address or parameters. The trusted root obviously 
protects the router IP address and router parameters. 
Whether the trusted root authorization also 
protects the mapping to a link-layer address, can 
be argued both ways. Anyway, it never makes sense 
to use only the CGA authorization method for RAs.

Proposal: Modify the text in Section 9.2.1:
"The outbound security associations used for this 
MUST be configured with the sender's key pair. The 
security association MUST be configured to protect 
the advertisement with the trusted-root 
authorization method and MAY be configured to 
additionally protect it with the CGA authorization 
method." 

Modify the text in Section 9.2.1:
"The inbound security associations used for this 
MUST be configured to require the trusted-root 
authorization method and they MAY additionally be 
configured to require CGA authentication." 

*13*
Section 9.3.1 (Redirect and CGA)

Unlike I earlier thought, it actually makes sense 
to use the CGA authorization mechanism for Redirect 
messages. The recipient of the Redirect already 
knows the IP address of the router because it just 
tried to send a packet via that router. Thus, the 
CGA authorization method can be used to verify that 
the Redirect comes from that router. (RFC 2461 
Section 8.1 effectively requires the recipient to 
check that the sender of the Redirect is a router.)

Proposal: No changes needed here. Redirect needs to 
be mentioned in draft-ietf-send-cga along with the 
other message types.

*14*
Section 9.3.1 (Target link-layer address 
option in Redirect)

The Target link-layer address option in the Redirect 
message is an oddity. In all the other types of 
messages, the AH proves that the node *owns*
the IP 
Source Address and is thus authorized to change its 
mapping to link-layer addresses. In Redirect, it is 
not the IP Source Address that is being mapped but 
the Target Address. The authorization comes from the 
fact that the sender of the Redirect is a router. 

Proposal: No changes needed but perhaps this should 
be discussed in the security considerations. 
Alternatively, ban the Target link-layer address 
option in SEND Redirect messages. 

*15*
Section 10.1, 2nd major bullet (insecure DAD)

There is nothing wrong here but a small clarification 
could be added.

Proposal: Add the following sentence: 
"Any insecure Neighbor Advertisements received in 
response to the insecure Neighbor Solicitation MUST 
be ignored."

*16*
Section 10.1, host considerations (SEND for all 
addresses)

Is there any reason why a host could not use SEND 
for some addresses and ND for others? This seems like 
an arbitrary and unnecessary limitation. 

Even if most hosts don't need to use both SEND and 
ND, some hosts may want to do so. For example, 
consider multi-homed hosts that have one interface 
on a physical network that has a SEND router and 
another interface on a physical network that has 
no SEND router. It should nevertheless be able to 
connect to both networks. 

Proposal: Allow host to use both SEND and ND. 

--------------------------------------------------------------------
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: Sun, 15 Jun 2003 11:52:15 +0300

Thank you Tuomas very much for these comments!
Inline.

> draft-ietf-send-psreq-03.txt) may also need revising.

Right. New text:

"NUD is security-sensitive, because an attacker could falsely
claim that reachability exists when it in fact does not."

> 8-bit Chain Number field and an 8-bit Component field.

You are right, of course about the problem.
It does appear only if you run several ADD procedures
in parallel. Hmm... this appears to be necessary
in some cases, such as when different types of
solicitations are sent in.

Thinking some more about this... the identifier field
appears to be able to distinguish such chains from
each other, but only in the case of solicited advertisements,
because the Identifier field is zero otherwise.

We also have the Trusted Root option, but that appears
currently only in the first component.

How about making the Trusted Root option appear in all
components, and required to be the first option?

> Section 6.5 (Authorization chain)

I'll leave this to Pekka and James who have indeed
are aware of the problem, I think, and have discussed
this with various folks in the IETF. My understanding
is that the discussions haven't concluded yet...

> Advertisements that do not form a chain starting 

Yes. Your text looks good. I would like to propose a
slight modification of the protocol to make this work
better: we can additionally require that the routers
send certs starting from the trusted root side of the
chain. This makes it possible to store only those certs
that really have a verifiable chain to the trusted root.
If another order would be allowed, then we would potentially
have to store a lot of certificates before being able to
verify that the chain ends in the root.

Here's the text:

"Hosts SHOULD store certificate chains retrieved in Delegation Chain
Discovery messages if they start from a root trusted by the host. The
certificates chains SHOULD be verified before storing them. Routers
are required to send the certificates one by one, starting from the
trusted root end of the chain. Except for temporary purposes to allow
for message loss and reordering, hosts SHOULD NOT store certificates
received in a Delegation Chain Advertisement unless they contain a
certificate which can be immediately verified either to the trusted
root or to a certificate which has been verified earlier."

> draft-ietf-send-cga-00. (I don't have any personal 

Changed to 1024.

> text in draft-ietf-send-cga-00 to match this.

I added this text. But I would suggest actually
deleting minSec, because if we don't have a reason
for it now, we shouldn't be specifiying it either.
There is no backwards compatibility issue for adding
such support later, since this does not relate to
on-the-wire issues.

> that can get the above 4 values.

Excellent idea, thanks! Here's the text:

"  authorization method

       This parameter determines the mechanisms through which the
       authority of the sender is determined.  It can have four values:

       trusted root

          The authority of the sender is verified as described in Section
          6.5.  The sender may have additional authorization through the
          use of CGAs, but this is neither required nor verified.

       CGA

          The CGA property of the sender's address is verified as
          described in [27].  The sender may have additional authority
          through a trusted root, but this is neither required nor
          verified.

       trusted root and CGA

          Both the trusted root and the CGA verification is required.

       trusted root or CGA

          Either the trusted root or the CGA verification is required."

> Proposal: Revise the text to reflect the above.

Right. Thanks. New text: "If anti-replay has been enabled,
receivers MUST be configured with an allowed Delta value.
They MUST maintain a cache of the last received timestamp
value from each specific source address within this time
period."

> Proposal: Add the above sentence to section 8.4.

Ok.

> Advertisement is equal to the IP Source Address 

Ok, thanks.

> of whether the option is present or not."

Ok, but I don't think we need to say anything in
9.2.1, since there does not appear to be any action
related to this.

> to use only the CGA authorization method for RAs.

I agree, mostly. But the use of CGA to protect
routers is still marginally better than plain ND.
So I'd rather use a SHOULD than a MUST in your
suggested text.

> configured to require CGA authentication." 

Put to the draft, with a SHOULD in place of the MUST
for the authz method.

> messages. The recipient of the Redirect already 

Hey, I knew this earlier ;-)

> be mentioned in draft-ietf-send-cga along with the 

Ok.

> option in SEND Redirect messages. 

Hmm... I'd rather ban the TLA option here.
This problem appears to apply both the trusted
root and CGA authz.

> response to the insecure Neighbor Solicitation MUST 

Added.

> Proposal: Allow host to use both SEND and ND. 

Sounds right, but is this for different addresses,
different routers, or for different interfaces? I have
tentatively edited the draft to say that hosts may
have different configs regarding this on different
interfaces.

Modified draft on the web at
   http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ipsec.txt
   http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ipsec.html
   http://www.piuha.net/~jarkko/publications/send/drafts/draft-send-ipsecdiff.html

--Jari

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 15 Jun 2003 15:35:18 +0300

> thought I'd rant a bit about it.

As Jari mentioned, we are aware of this problem.
We have been conducting off-line discussions with
various folks about this issue.

RFC3281 currently has a restriction that the
Issuer cannot be a hash of a public key.  However,
the necesassary ASN.1 encoding is there, the RFC
just forbids one from using that reature.

I have proposed lifting the restriction.  However,
so far I haven't seen any real response.

--Pekka Nikander

---

From: "James Kempf" <[email-masked]>
Date: Mon, 16 Jun 2003 14:06:36 -0700

> root or to a certificate which has been verified earlier."

How about:

    Hosts SHOULD store certificate chains received in Delegation Chain
    Discovery messages if they start from a root trusted by the host.
The
    certificate chains SHOULD be verified before storing them. Routers
    MUST send the certificates one by one, starting from the trusted
    root end of the chain. Except for temporary purposes to allow for
    message loss and reordering, hosts SHOULD NOT store certificates
    received in a Delegation Chain Advertisement unless they contain a
    certificate which can be immediately verified either to the
trusted
    root received as the first certificate in the chain, to a trusted
root
    currently held by the host, or to a certificate which has been
    verified earlier.

            jak