Subject: CGA Issue #7: Strengthening Section 7.4 (Ted Hardie)

From: "Tuomas Aura" <[email-masked]>
Date: Mon, 22 Mar 2004 13:35:11 -0800

Ted Hardie:

Comment:
The following text is fundamentally good:

   Finally, some cautionary notes should be made about using CGA-based
   authentication for other purposes than SEND. First, the other
   protocols should include type tags and the sender address in all
   signed messages in the same way as SEND does. Because of the
   possibility of related-protocol attacks, it is advisable to use the
   public key only for signing and not for encryption. Second, CGA-based
   authentication is particularly suitable for securing neighbor
   discovery [RFC2461] and duplicate address detection [RFC2462] because
   these are network-layer signaling protocols where IPv6 addresses are
   natural endpoint identifiers. In any protocol that aims to protect
   higher-layer data, CGA-based authentication alone is not sufficient
   and there must also be a secure mechanism for mapping higher-layer
   identifiers, such as DNS names, to IP addresses.

In that it discourages folks from using CGA-based authentication alone.
I'd
suggest strengthing it even further, though.  Would something like the 
following text be acceptable?

CGA-based authentication should not be considered for purposes other
than SEND and closely related mechanisms.  CGA-based authentication 
is particularly suitable for securing neighbor discovery [RFC2461] and 
duplicate address detection [RFC2462] because these are network-layer 
signaling protocols where IPv6 addresses are natural endpoint
identifiers. 
In any protocol that aims to protect higher-layer data, CGA-based 
authentication 
alone is not sufficient as there must also be a secure mechanism for 
mapping higher-layer identifiers, such as DNS names, to IP addresses.
Further, using CGA-based authentication for other purposes may
weaken the effectiveness of this mechanism for SEND, because of the
possibility of related-protocol attacks.  If another mechanism needs
to re-use CGA-based authentication, it must take care that it 
include type tags and the sender address in all signed messages in the 
same way as SEND does and  it must use the public key only for signing
and 
not for encryption.

---

Tuomas Aura:

I suggest the following wording:

   Finally, a strong cautionary note needs to be made about using 
   CGA-based authentication for other purposes than SEND. First, the 
   other protocols MUST include a type tag and the sender address 
   in all signed messages in the same way as SEND does. Each protocol
   MUST define its own type tag values as explained in Section 8. 
   Moreover, because of the possibility of related-protocol attacks, 
   the public key can be used only for signing and it MUST NOT be used 
   for encryption. Second, CGA-based authentication is particularly 
   suitable for securing neighbor discovery [RFC2461] and duplicate 
   address detection [RFC2462] because these are network-layer 
   signaling protocols where IPv6 addresses are natural endpoint 
   identifiers. In any protocol that aims to protect higher-layer 
   data, CGA-based authentication alone is not sufficient and there 
   must also be a secure mechanism for mapping higher-layer identifiers,

   such as DNS names, to IP addresses. If the primary goal is not to 
   authenticate an IPv6 address, CGA-based authentication is probably 
   not the right solution.

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

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 29 Mar 2004 18:20:41 +0200

>    authenticate an IPv6 address, CGA-based authentication is probably

Looks good to me.  My only question is whether the expression
"to authenticate an IPv6 address" is unambiguous enough?  In the past,
there has been some confusion about how, exactly, does CGA provide
"authentication".  But perhaps this has already been discussed elsewhere
in the document?

--Pekka

---

From: Jari Arkko <[email-masked]>
Date: Wed, 31 Mar 2004 21:41:18 +0300

>  authenticate an IPv6 address, CGA-based authentication is probably 

I basically agree with the sugggested text, with one
proposed change.

The CGA technique, as well as other infrastructureless
techniques, is very much tied together with the semantics
of the application it protects. This applies to all
security mechanisms of course, but for for these techniques
the linkage is very tight. Its kind of hard to give
exact rules on when its applicable and when its not,
however. In particular, I suspect there are cases
where CGA could be used even for higher layer applications,
as long as the IP address is the identifier used in
that application. Also, taking "protect higher-layer
data" literally would also preclude using CGAs to
bootstrap IP layer encryption, which would also seem
to be possible. So how about changing

   In any protocol that aims to protect higher-layer

to

   In any protocol that aims to use other identifiers,
   CGA-based authentication alone is not sufficient to protect
   the application. There must also be a secure mechanism for
   mapping higher-layer identifiers, such as DNS names, to
   IP addresses. If the primary goal is not to authenticate
   an IPv6 address, CGA-based authentication is probably
   not the right solution.

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Wed, 31 Mar 2004 10:59:39 -0800

I agree, with the provision that CGAs don't provide authentication, they
prove authorization. Hence I'd suggest the following rewording:

    In any protocol that aims to use other identifiers,
    CGA-based authorization alone is not sufficient to protect
    the application. There must also be a secure mechanism for
    mapping higher-layer identifiers, such as DNS names, to
    IP addresses. If the primary goal is not to deterimine the
    authorization to make claims about an IPv6 address, CGA-based
    authorization is probably not the right solution.

and changing "authentication" to "authorization" in the rest of the
paragraph.

This still leaves open the possibility for using CGA for other applications
that want to make a claim about the right to do something with an IPv6
address (provided the IPR issue is solved), for example, a claim to be able
to change the routing that might be part of a Mobile IPv6 BU security
mechanism for route optimization.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Wed, 31 Mar 2004 22:39:30 +0300

Ok.