Subject: [CGA-EXT] Review draft-ietf-csi-proxy-send-01

From: Roque Gagliano <[email-masked]>
Date: Mon, 7 Dec 2009 02:18:42 +0100

I reviewed the documents and here are my comments. Overall I found it clear and easy to read. 

Regards,

Roque.

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

1) 
Abstract:

As specified today SEND assumes that the node advertising
                     ^^^^^^
                    in RFC 3971

2) General comment on "ownership" of IP addresses:
The documents mentions in several parts that a host "owns" an address or a prefix. Coming from the registry world, I can say that it is not the correct terminology. IP addresses are not owned, they are allocated or assigned. Then configured (dynamically or statically) in an interface. Ownership has a meaning of property that should not be used.

3) Section 4.1
A ND Proxy shall parse any IPv6 packet it receives on a proxy interface to check whether it contains one of the following ICMPv6 messages: Neighbor Solicitation (NS), Neighbor Advertisement (NA), Router Advertisement (RA), or Redirect.
  ^^^^^
Router Solicitation messages are missing, these are needed in example 3.

4) Section 5.

Paragraph 1: 
It is written as if Proxy SEND only applies to RA and RS as it mentions "assume that the owner of the address was the one who was advertising the prefix". I rather say: "the address or prefix was configured in the node originating the ND message".

Bullet 1: 
s/krishnan-cgaext-send-cert-eku/ietf-csi-send-cert-01
The document is now a WG item.

Bullet 2:
s/has/hash

5) Section 6.1 Proxy Signature Option.
Here is my biggest issue, there is no possibility of transitioning from one algorithm to another, the document sticks with SHA-1 as hashing algorithm  and RSA/SHA-1 for signature. Working in another protocol, the SEC ADs made it clear that they are looking at documents to make sure that there is a way to change the crypto algorithms if needed. The host receiving the NDP message from the SEND Proxy needs to know the signature alg. that is being used. One solution to this issue is to define 8 bits of the Reserved bits where 4 of them define the hash algorithms and the other 4 the  signing algorithm. A transition mechanism could be to include two PSOs extensions, one with each set of algorithms.

I know this may also have to do with the protocol agility discussion. Again, you could check with the SEC ADs if this would be an issue for them.

6) Normative references:
s/krishnan-cgaext-send-cert-eku/ietf-csi-send-cert-01
The document is now a WG item.

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 7 Dec 2009 09:57:20 -0800

Ok. How about?

As specified in the current SEND specification [RFC3971], it is assumed that the node advertising...

> The documents mentions in several parts that a host "owns" an address
> or a prefix. Coming from the registry world, I can say that it is not
> the correct terminology. IP addresses are not owned, they are allocated
> or assigned. Then configured (dynamically or statically) in an
> interface. Ownership has a meaning of property that should not be used.

Well, actually that's a feature of CGA's, one can show proof-of-ownership by signing with the CGA's private key. I own my CGA because I generated it and the corresponding key pair, and you do not own it and you can't show proof of ownership because you don't have the private key.

So I think we want to keep using that term.

I can agree that we don't want to talk about a prefix owner, though, but I don't think we're doing that in the document. 

> 3) Section 4.1
> A ND Proxy shall parse any IPv6 packet it receives on a proxy interface
> to check whether it contains one of the following ICMPv6 messages:
> Neighbor Solicitation (NS), Neighbor Advertisement (NA), Router
> Advertisement (RA), or Redirect.
>   ^^^^^

The section 4.1. describe the RFC4389 use case. In this use case Router Solicitations (RS's) negotiate no link layer address and thus they do not require specific treatment compared to regular IPv6 data packets, as opposed to the messages listed above, NS, NA, RA and Redirect.

> 4) Section 5.
> 
> Paragraph 1:
> It is written as if Proxy SEND only applies to RA and RS as it mentions
> "assume that the owner of the address was the one who was advertising
> the prefix". I rather say: "the address or prefix was configured in the
> node originating the ND message".

Ok.

> Here is my biggest issue, there is no possibility of transitioning from
> one algorithm to another, the document sticks with SHA-1 as hashing
> algorithm  and RSA/SHA-1 for signature. Working in another protocol,
> the SEC ADs made it clear that they are looking at documents to make
> sure that there is a way to change the crypto algorithms if needed. The
> host receiving the NDP message from the SEND Proxy needs to know the
> signature alg. that is being used. One solution to this issue is to
> define 8 bits of the Reserved bits where 4 of them define the hash
> algorithms and the other 4 the  signing algorithm. A transition
> mechanism could be to include two PSOs extensions, one with each set of
> algorithms.
> 
> I know this may also have to do with the protocol agility discussion.
> Again, you could check with the SEC ADs if this would be an issue for
> them.

The lack of algorithm agility is generic to SEND and not specific to the Secure Proxy ND mechanism. When the WG concludes on how to move forward with algorithm agility, we can publish an RFC updating both RFC3971 and this to be RFC to add algorithm agility. 
 
> The document is now a WG item.

Ok.

--julien

---

From: Roque Gagliano <[email-masked]>
Date: Wed, 9 Dec 2009 12:13:55 +0100

Julien,

> I can agree that we don't want to talk about a prefix owner, though, but I don't think we're doing that in the document. 

I understand, but CGA only refers to IIDs not to the complete address (including the prefix). Coming from the addressing world I have to make the distinction. In our world we talk about "right of use" and not ownership. This means, I have the right of USING this CGA because I have possession of the correspondent private key.

That is something I made clear in the CERT draft.

> The lack of algorithm agility is generic to SEND and not specific to the Secure Proxy ND mechanism. When the WG concludes on how to move forward with algorithm agility, we can publish an RFC updati…

So, we know there is a problem and probably know that SEC ADs are looking at these particular issues, however we would to advance this draft to the IESG hopping that it passes their LC with the promise to solve the issue later on? I only have been in CSI for a couple of months but does not sound proper IETF process to me.

The agility discussion also included a signaling between the parties in order to select which algorithm to use. What we can do while that discussion is not over in the WG is to make sure that new SEND options have the possibility of identifying which algorithms each party are using, leaving the signaling part for later. This is similar to DNSSEC where in order to change from SHA-1 to SHA-256 probably all signatures will be for a while duplicated in the zone files.

Roque.

-------------------------------------------------------------
Roque Gagliano
LACNIC
[email-masked]
GPG Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 6CEE

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 9 Dec 2009 09:00:59 -0800

Hi Roque -

> I understand, but CGA only refers to IIDs not to the complete address (including the prefix). 

CGA generation _and_ proof-of-ownership are tied to the CGA's prefix thus I disagree with your statement above.
 
> Coming from the addressing world I have to make the distinction. In our world we talk about "right of use" and not ownership. This means, I have the right of USING this CGA because I have possession of the correspondent private key.

A first observation is that the term ownership is used extensively in the CGA related literature.
 
That being said, you seem to be opposing ownership and right of use in this context when there's no need to. There's quite a difference between the two and not specific to that context. I might well own something and have no right to use it, e.g., a car, a plane, a gun.

So in terms of prefix I agree that you want to use right of use rather than ownership, but in terms of CG-addresses, IMHO we do want to say ownership.

> That is something I made clear in the CERT draft.

But the focus of the CERT draft is on delegating authorization to advertize/use prefixes or addresses that are NOT cryptographically generated, thus there's no ownership involved.

> The agility discussion also included a signaling between the parties in order to select which algorithm to use. What we can do while that discussion is not over in the WG is to make sure that new S…

Would inclusion of an algorithm field in the PSO solve your concern?

--julien

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 10 Dec 2009 01:09:28 +0100

Hi Julian,

> So in terms of prefix I agree that you want to use right of use rather than ownership, but in terms of CG-addresses, IMHO we do want to say ownership.

The distinction is not so clear for me but I am fine with "no innovating". 

> Would inclusion of an algorithm field in the PSO solve your concern?

IMHO, it will help to move the document through the next step.

Roque.

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 10 Dec 2009 01:14:29 +0100

Julien,

You can even include Tonys text about "Signature Algorithm":
"
   Signature Algorithm

      A one-octet long field indicating a signature algorithm and the
      corresponding hash algorithm that this node supports; this support
      implies at least ability to verify signatures of this Signature
      Algorithm algorithm.

      If the first leftmost bit, bit 0, is set to 0, it indicates that
      the emitter is able to perform signature checks only (i.e. no
      signature generation with this type of signature algorithm).  If
      this bit is set to 1, it indicates that the emitter has a public
      key of this type and can generate signatures.  Bit 1 and 2 are
      reserved.  Bit 3 to 7 are named Signature Type Identifier subfield
      and encode an identifier for the signature algorithm and
      corresponding hash algorithm.  Default values for the Signature
      Type Identifier subfield defined in this document are taken in
      part from the IANA-defined numbers for the IKEv2 protocol, i.e.
      IANA registry named "IKEv2 Authentication Method":

      *  Value 0 is RSA/SHA-1 (compatible with [RFC3971])

      *  Value 1 is RSA/SHA-256

      *  Section 5 of document [cheneau-csi-ecc-sig-agility] provides
         values for ECDSA signature algorithm
"
Roque.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 10 Dec 2009 17:05:07 +0200

I have reviewed this draft.

In general, I'm quite happy with the approach it takes with respect to 
authorizing proxies with an explicit authorization certificate. I think 
it is a good and sufficient approach.

I do have a number of other technical issues, however. My biggest issue 
is that this specification could do a much better job with respect to 
backwards compatibility and mixed nd/send/proxy environments.

> It is not possible to apply the current SEND specification to protect
> the NA message issued by the HA. 

Strictly speaking this is not entirely correct. You only cannot support 
certain modes of operation. For instance, the virtual home link 
operation is trivially compatible with SEND. Also, since the home agent 
and the mobile node need to agree on a home address, the actual owner of 
the IP address (and corresponding private keys) could be either the home 
agent or the mobile node. Current SEND specifications do not support 
signatures for the same address coming from either the home agent or the 
mobile node. But it would be possible for the home agent to sign the NA 
messages, if it was the original owner of the home address. I'm not sure 
any of this has much practical significance, but I wanted to bring this 
up anyway, because the statements in the draft should be correct.

> The approach described above and the current SEND specification are
> incompatible since:
>
>   Sharing the same link-local address on different MAGs would
>   require all MAGs of a PMIPv6 domain to construct the CGA and the
>   RSA Signature option with the same public-private key pair, which
>   is not acceptable from a security point of view.
>   

AFAIK there is no requirement that routers construct CGAs.

> 4. Application Scenarios

There seemed to be some duplication with respect to 
draft-ietf-csi-sndp-prob.

> When any of these
> messages is received with a valid Proxy Signature option, it is
> considered as secure even if it doesn't contain a CGA option.
>   

I think there needs to be a difference with respect to whether the 
original message had a CGA option or not. The receiver on the other side 
needs to know this in order to decide whether to override an cache entry 
or not, in a manner similar to what RFC 3971 already does.

>       This field starts after the Key Hash field.  The length of the
>       Digital Signature field is determined by the length of the RSA
>       Signature option minus the length of the other fields (including
>       the variable length Pad field.)
>
>    Padding
>
>       This variable-length field contains padding, as many bytes long as
>       remain after the end of the signature.
>   

I don't understand how to calculate the length of the Signature field, 
because the padding field's length is not described anywhere.

> The modifications described in the following section applies when a
> SEND message contains the Proxy Signature option (PSO), i.e. the
> message was sent by a Secure Proxy ND.
>   

This does not seem like the only required modification. I would also 
like to see what a host on the other end should do if it has a cache 
entry that came from a PSO signed SEND message, and the host now 
receives a classic 4861 or 3971 message.

> When any of these
> messages is received with a valid Proxy Signature option, it is
> considered as secure even if it doesn't contain a CGA option.
>   
...
> A ICMPv6 message sent by a Secure Proxy ND for a proxied address MUST
> contain a Proxy Signature option (PSO) and MUST NOT contain CGA and
> RSA Signature options.
>   

I read the first statement as the CGA being optional, and now you are 
saying its a MUST NOT. Maybe the first statement needs to be made clearer.

Nevertheless, wouldn't it be good if the proxy didn't actually remove 
any information from the messages? First of all, its a little bit tricky 
to ensure that a proxy is capable of removing all SEND options that 
might be defined over time. Secondly, it seems like the wrong thing to 
do conceptually. You want to inform the other side that this message was 
proxied, but you may also want to know that the message was initially 
signed. This can be important, for instance, to decide whether to 
override a cache entry. I would not override a secure entry based on a 
securely proxied insecure message, for instance.

> 7. Backward Compatibility with legacy SEND nodes
The specification does not explain how a receiver treats different 
combinations of existing cache entries involving a ND, SEND, or proxy 
SEND source and a new message from a ND/SEND/proxy SEND source.

Finally, I'm not sure the draft does a good job of explaining which 
scenarios it covers from sndp-prob and which not. FWIW, I think this 
draft is all we need and we do NOT need to cover all possible scenarios 
from sndp-prob. But the readers would still like to understand the 
situation.

Jari

---

From: Tony Cheneau <[email-masked]>
Date: Thu, 10 Dec 2009 22:57:18 +0100 (CET)

Hello Roque,

The text you extracted corresponds to a part of the Supported Signature
Option. The only part that is interesting here is the Signature Type
Identifier that can be stored in the Reserved field of the PSO.  Maybe a
more relevant text would be:

  Signature Type Identifier is a 5-bit field.  It corresponds to the
  Signature Type Identifier subfield (bits 3 to 7 of the Signature
  Algorithm field) in the Supported Signature Algorithm option (defined in
  [draft-cheneau-csi-send-sig-agility-01]).  It indicates the type of
  signature contained in the Digital Signature field.

And this kind of PSO format:
         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |    Length     |      Reserved       |   STI   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        |                          Key Hash                             |
        |                                                               |
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        .                                                               .
        .                       Digital Signature                       .
        .                                                               .
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        .                                                               .
        .                           Padding                             .
        .                                                               .
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I think that the working group should discuss on what mechanism is to be
allowed for  Signature Agility in the newly defined * Signature Option
(PSO, here, but also Universal Signature Option). For example, we could
only require a 5 bit field as proposed here. This would allow us to
define new option and such, while waiting for a complete solution to be
approved by the working group.
What do you think ? Is that obvious or should we speak this any further
?

Regards,
 	Tony

---

From: Tony Cheneau <[email-masked]>
Date: Thu, 10 Dec 2009 23:37:15 +0100 (CET)

Hello Jari,

I'm not author of this document, but I implemented a bit of the SEND

> because the padding field's length is not described anywhere.

The padding field is exactly defined this way in RFC 3971 (although a
Pad Length field was present on the -04 version of the SEND draft). 
I think the draft-ietf-csi-proxy-send-01 document only reuses the format
of the badly defined RSA Signature Option.

In the RSA signature option, you can check with the Key Hash field which
Public Key is linked to the Digital Signature field (it is often carried
by the CGA Option).  Then, the Public Key length determines the size of
the Digital Signature (1024 bits long key = 128 octets long Digital
Signature). Hence, you have a way to determine the size of the padding.

If you use a different Signature Algorithm with a varying Digital
Signature size, you still can choose to encode it in a DER-like format
(but this is mostly an hack...).

If RFC 3971 was to be updated, I agree that a padding length field should 
be defined somewhere in the RSA (or XXX) Signature Option. 
Was there a rational behind its removal during the RFC 3971
standardisation process ?

Regards,
 	Tony

---

From: Jari Arkko <[email-masked]>
Date: Fri, 11 Dec 2009 07:37:05 +0200

Tony,

> Pad Length field was present on the -04 version of the SEND draft). I 
> think the draft-ietf-csi-proxy-send-01 document only reuses the format

Ah, OK.

> If RFC 3971 was to be updated, I agree that a padding length field 
> should be defined somewhere in the RSA (or XXX) Signature Option. Was 
> there a rational behind its removal during the RFC 3971

I can't recall. Maybe this is one of the bugs that we need to fix. Or 
perhaps there is a way to determine the lengths but neither of us can't 
just see it right now. In any case, it should be clearly specified in 
3971bis and the proxy-send drafts.

Jari