Subject: Re: [karp] Stephen Farrell's Discuss on draft-ietf-karp-design-guide-03: (with DISCUSS and COMMENT)

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 22 Sep 2011 10:36:00 -0400

Additional follow ups, based on clarifications from Stephen, which are I 
believe now actionable for the authors.

On 9/22/2011 8:12 AM, Stephen Farrell wrote:
> Hi Joel,
...
>>> (3) Section 2 calls out "several" categories (though only two are
>>> identified?) and says that the hope is to have one design team per
>>> category, and "down the road," one KMP per category. I don't
>>> understand what's being presented here, e.g. how many KMPs are
>>> envisaged - just two (mapping to sections 2.1 and 2.2) or something
>>> else?
>>
>> The "several" I believe is because in earlier versions there were moe
>> branches, and it got pruned. In terms of gap analysis, it is varying
>> whether we have a design team for the category, or for the individual
>> protocol. In part this is because there is more variation among some
>> subsets than others.
>> With regard to the number of KMPs, the effort was to write this to
>> reinforce that fewer distinct protocols is better, but not to decide the
>> question of whether we have 1 or 2.
>> Can you suggest modifications that would make this clearer?
>
> Enumerating the planned design teams clearly. A list should do it.

Please add the above enumeration to the document.

>
>>> (4) I don't get why 3.1 talks about SHA-1 fingerprints. It seems
>>> very unlikely that any new KMP would use SHA-1 like this.
>>
>> Is there some simple mechanism we should describe instead?
>
> I don't believe you're at the point of identifying mechanisms
> yet, never mind hash functions and even if you were then you
> would not, today, pick sha-1. (Its no longer "modern":-)

Please remove the reference to sha-1, and find a better way to say what 
we mean.

>
>>> (5) Are you really saying that keys MUST (in 2119 terms) be changed
>>> "when an operator leaves" (section 3.2)? That seems plain wrong.
>>
>> That does seem too strong. I will send a separate note to the KARP list
>> to see if we can weaken it. Would changing that to a "should" work for
>> you?
>
> Don't think so. I guess operators employ a lot of people and store
> thousands of keys. Not all keys should be changed when any employee
> leaves. Saying "sometimes, you may need to change a key after an
> employee has moved on" would be fine. But doesn't seem that interesting.
> Maybe just delete the sentence?

I think we want to leave the reference to employees departing.  But It 
clearly needs much clearer wording.
While just saying that we mean employees with key access, that is also 
slightly misleading (as who really has key access can be ambiguous), so 
this needs to be toned down to a description a common concern.

...

>>> (7) Section 6 says "while defining the new...mechanisms." Why
>>> are you ruling re-use of existing mechanisms out of scope?
>> The mechanism is at the very least new to the context where it is being
>> introduced. The intention is definitely NOT to prohibit reuse of
>> technology (IKE/IPSEC, or any other existing security technology. But if
>> it were already being used fully and properly, then the design team
>> would simply say "nothing to do", which would be veyr nice. The new is
>> because they are introducing something. Can you help with wording to
>> make that clearer?
>
> Say that "If new mechanisms are needed, then..." and that'd be fine.
>
>>> (8) Section 7.4 seems to say that if a PSK is stolen, that that
>>> doesn't expose the traffic key presumably derived from the PSK via a
>>> standard, openly defined KMP. That just seems wrong. The text in
>>> question is: "They may gain access to key derivation material, like a
>>> PSK, but not current traffic keys in use."
>>
>> The document does seem to be making too strong a claim here. We need
>> clearer words. After all, TCP-AO has the property that if the pre-shared
>> key is known, then the session keys are also known. (I think that is
>> your point Stephen?)
>
> Right.

As sent earlier, Stephen confirms the understanding of what needs to be 
fixed here.

Yours,
Joel