Subject: Re: Gen-ART Last Call Review of draft-ietf-mipshop-cga-cba-02.txt

From: Christian Vogt <[email-masked]>
Date: Wed, 31 Jan 2007 18:47:50 +0100

Hello Eric,

thank you for taking your time to review draft-ietf-mipshop-cga-cba.
Please see my comments in-line below.

Note I'm also sending a CC to [email-masked] as suggested in the IESG's 
Last Call announcement on the Mipshop working group's mailing list.

> Summary:
> 
> I have a small number of comments and/or questions on this draft.  From
> a generalist perspective, this is a very well written and - for the
> complexity of the protocol involved - relatively easy to read document.
> 
> 
> Comments: 
> ____________________________________________________________________
> 
> Security section (2.2), top of page 8, lists ability to "securely 
> authenticate mobile nodes without preconfigured credentials or a 
> public-key infrastructure" as an objective of this protocol.
> 
> I don't see how it is possible to avoid requiring public keys for 
> Cryptographically Generated home Addresses - in particular - since 
> section 3.1 seems to say that CGA results in a binding between each 
> mobile node's home address and that mobile node's public key, thus 
> allowing other nodes to securely authenticate the mobile node.
> 
> Even though this is done infrequently to establish a semi-permanent 
> security association, it is done at least once (during establishment of
> an initial registration association between a pair of mobile and 
> correspondent nodes) - hence there seems to be some dependence on 
> public key infrastructure.
> 
> I don't know how to fix this - or even if it needs fixing - but it 
> might be useful to qualify this "objective" using "ideally".  If, on 
> the other hand, this objective is actually met, I did not see where 
> this is explained.  Is it met, and - if so - is it explained?

The objective is actually met, but I see your point that this is not made
clear in the draft.

Specifically:  It is true that a node needs a public/private-key pair in
order to generate a CGA and to prove ownership oFrom [email-masked] Wed Jan 31 12:53:22 2007
Date: Wed, 31 Jan 2007 12:47:34 -0500
From: John C Klensin <[email-masked]>
To: "Steven M. Bellovin" <[email-masked]>
Cc: Ned Freed <[email-masked]>, [email-masked]
Subject: Re: Referencing BCPs [Re: ion-procdocs open for public
 comment]

--On Wednesday, 31 January, 2007 17:02 +0000 "Steven M.
Bellovin" <[email-masked]> wrote:

> On Wed, 31 Jan 2007 11:54:26 -0500
> John C Klensin <[email-masked]> wrote:
> 
>> 
>> Except for the fact that the material being cited contains the
>> specifics of license and IPR releases, and promises to abide
>> by certain rules, by the authors.  Authors can't reasonably be
>> asked to agree to something that might be published under the
>> BCP number in the indefinite future, so you are either stuck
>> with a document (RFC) number or a BCP as of a specific date,
>> which amounts to the same thing and is harder to track down.
>> 
> 
> I'll let Jorge correct me if I'm wrong, but referencing by
> <number,date> is the norm in the legal world, since statutes
> do get amended without necessarily being renumbered.

I believe that is correct.  The problem here is that, as a
consequence of that referencing system, they have taken measures
to be sure that the version corresponding to the reference is
readily available.  We don't do that: finding out what was
actually BCP NNN on some particular date requires both skill and
out of band knowledge.

> I do agree we want to make it easy for non-lawyers.  I've
> suggested a date-stamped archive of each version of each such
> document, for precisely that reason. 

That, of course, would do that job and eliminate all of my
objections.  But it does mean that, for many purposes, we can't
use a reference to "BCP nnnn", it must be a reference to "BCP
nnnn as of yyyymmdd" or its equivalent.

      john

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Eric Gray \(LO/EUS\)" <[email-masked]>
Date: Wed, 31 Jan 2007 17:51:20 -0600

For some reason, in your response, my "bulletization" of the
list of the new status codes somehow got "re-paragraphed" -
hopefully my version below does not suffer the same fate.

Typographical "resets" should be absolutely disallowed in 
E-Mail.  :-)

To the casual reader, it may otherwise be unclear exactly
what change I was suggesting...

> -----Original Message-----
> From: Christian Vogt [mailto:[email-masked]] 
> Sent: Wednesday, January 31, 2007 12:48 PM
> To: Eric Gray (LO/EUS)
> Cc: Wassim Haddad (KI/EAB); Jari Arkko (JO/LMF); Mark 
> Townsley; [email-masked]; [email-masked]
> Subject: Re: Gen-ART Last Call Review of 
> draft-ietf-mipshop-cga-cba-02.txt
> 
> Hello Eric,
> 
> > security association, it is done at least once (during establishment
> > of an initial registration association between a pair of mobile and 

> The objective is actually met, but I see your point that this is not
> made clear in the draft.
> 
> order to generate a CGA and to prove ownership of this CGA to its
peers.
> Yet such an IP address ownership proof still does not require a PKI.
In
> general, a PKI provides a secure binding between a node's identifier
and
> public key, but in the case of a CGA, the CGA itself is
cryptographically
> bound to the CGA owner's public key.  So where the CGA serves as an
> identifier for its owner -- as is the case in an IP address ownership
> proof --, no PKI is required.  This is the primary advantage of
CGA-based
> authentication compared to other public-key approaches.
> 
> To clarify this matter, I suggest to extend subsection 3.1.
> ("Cryptographically Generated Home Addresses") in the 
> "Protocol Design" section as follows:
> 
> OLD:
> 
>                                                   [...]  In general, a
>     CGA provides a strong binding between its interface identifier and
>     the CGA owner's public key.  This enables other nodes to securely
>     authenticate the CGA owner as such, modulo the correctness of the
>     CGA's subnet prefix.  [...]
> 
> NEW (shortened):
> 
>                                                   [...]  In general, a
>     CGA provides a strong, cryptographic binding between its interface
>     identifier and the CGA owner's public key.  This facilitates a
>     cryptographic home address ownership proof without a PKI, enabling
>     other nodes to securely and autonomously authenticate the CGA
owner
>     as such, modulo the correctness of the CGA's subnet prefix.  [...]
> 
> > I suggest changing the 2nd paragraph in IANA Considerations to read 
> > something like:
> > 
> > This document allocates the following four new status codes for
Binding
> > Acknowledgment messages:
> > 
> > "Permanent home keygen token unavailable", "CGA and signature
> > verification failed", "Permanent home keygen token exists", and 
> > "Non-null home nonce index expected"

   "Permanent home keygen token unavailable", 
   "CGA and signature verification failed", 
   "Permanent home keygen token exists", and 
   "Non-null home nonce index expected"

> > 
> > The values to be assigned for these status codes must all be greater
> > than or equal to 128, indicating that the respective Binding Update
> > message was rejected by the receiving correspondent node.
> 
> Yes, that would be more clearly arranged.  Will change it.
> 
> > I also suggest that this document should be accompanied with an 
> > explicit RFC Editor's note to replace TBD with IANA assigned values 
> > (as identified by associated parenthetical value names) in several 
> > places throughout the draft.  It would help if specific TBDs were 
> > distinct (e.g. TBD-1, TBD-2, TBD-3 and TBD-4) and these "variable" 
> > names then associated (perhaps in a table) with their meanings in 
> > the IANA considerations section.
> 
> Ok.  There are quite a number of numbers to be allocated by IANA, so 
> I see your point of making it a bit easier for IANA.

And slightly easier (== less error-prone) for the RFC Editor
as well...

> > Reference 6 ("Cryptographically Generated Addresses (CGA)" - RFC
3972)
> > should be Normative.
> Indeed.
> > NITs: ====
> > In the 3rd bullet of section 2.2 (Security), on page 7, it should be
> > "mobile or correspondent" verses "mobile and correspondent" (more 
> > inclusive as it is probably necessary only to victimize one or the 
> > other to effect a denial of service).
> 
> Yes, will change it.
> 
> > In the first bullet of the last set of (3) bullets on page 18, it is

> > really necessary to break this sentence up at least with commas - in

> > order to make it so a reader can parse it.  I suggest:
> > 
> > "If the Binding Update message is complete, the care-of nonce index
is
> > taken from the Care-of Test option or Care-of Test message with
which
> > the care-of keygen token (used to calculate the authenticator for
the
> > Binding Update message) was obtained."
> > 
> > Note that I use parens, rather than commas, to make the structure
more
> > readily apparent.
> 
> This is easier to parse, yes.  I'll change it.
> 
> > In section 6 (Security Considerations), the statement about changes
in
> > the security model - should the reference be [4], rather than - or
in
> > addition to - [1]?
> 
> Yes, the reference should be [4], and it should appear after "security
> model" rather than after "base Mobile IPv6".  Thanks for catching
this!
> 
> Eric, my co-authors and I appreciate your review.  Thanks again for 
> taking your time!

:-)

> 
> Regards,
> - Christian
> 
> -- 
> Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
> www.tm.uka.de/~chvogt/pubkey/
> 
> 
>