Subject: [karp] Question fro Security AD review

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 21 Sep 2011 11:42:38 -0400

Stephen noted that section 3.2 says taht keys "must" be changed when an 
operator who has access to them leaves.
It seems to me that such a a change is an operational matter, subject to 
operational trade-offs.  (Stephens reaction was stronger.)

Do we really want a "must" for this?

Thank you,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 21 Sep 2011 12:01:07 -0400

Since I managed to sloppily leave out the document title, this is about 
the design guidelines document.
Joel

On 9/21/2011 11:42 AM, Joel M. Halpern wrote:
> _______________________________________________
> karp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/karp
>

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 23 Sep 2011 06:54:06 +0530

Does the following text look ok:

"Cryptographic keys should have a limited lifetime and may need to be changed when an operator who had access to them leaves."

This is to address the ADs comment that operators could employ lot of people and may store thousands of keys. Not all keys would need to be changed when any employee leaves.

Cheers, Manav 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joel M. Halpern
> Sent: Wednesday, September 21, 2011 9:13 PM
> To: [email-masked]
> Subject: [karp] Question fro Security AD review
> 
> Stephen noted that section 3.2 says taht keys "must" be 
> changed when an operator who has access to them leaves.
> It seems to me that such a a change is an operational matter, 
> subject to operational trade-offs.  (Stephens reaction was stronger.)
>

---

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

That seems like it ought to suffice.  Stephen?
Thanks,
Joel

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Sep 2011 08:14:57 +0100

Works for me
S

---

From: Carter Bullard <[email-masked]>
Date: Fri, 23 Sep 2011 10:21:44 -0400

Gentle people,
I apologize for jumping in late, but there are lots of reasons why keys have limited lifetimes
and should be changed often (for some sites that is measured in geological time, but that
is still often).  And there are many, many approaches to key management.  It would seem
more appropriate to say something like:

   "Cryptographic keys should have a limited lifetime and should be managed
    using an effective management policy  (see RFC 2196, Secton 4.1, Authtentication
    as a guideline)."

Or you can reference section 4.1.4 Password Assurance, or something like that.

While to some this reference may seem dated, it is a reference to the IETF's Site Security
Handbook, which would be where a site would specify its master key management policy.

Hope this is helpful,

Carter

---

From: Russ Housley <[email-masked]>
Date: Mon, 26 Sep 2011 13:09:18 -0400

>    using an effective management policy  (see RFC 2196, Secton 4.1, Authtentication

Wouldn't RFC 4107 be a better reference?  Or, at least an additional reference.

Russ

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Tue, 27 Sep 2011 01:36:31 +0530

We do refer to RFC 4107 in Sec 3. I can refer to RFC 2196 and RFC 4107 when discussing cryto keys if that helps.

Cheers, Manav

> Behalf Of Russ Housley
> Sent: Monday, September 26, 2011 10:39 PM
> To: Carter Bullard
> Cc: [email-masked]
> Subject: Re: [karp] Question fro Security AD review
> 
> Carter:
> 
> > I apologize for jumping in late, but there are lots of reasons why 
> > keys have limited lifetimes and should be changed often (for some 
> > sites that is measured in geological time, but that is 
> still often).  
> > And there are many, many approaches to key management.  It 
> would seem more appropriate to say something like:
> >

---

From: Carter Bullard <[email-masked]>
Date: Mon, 26 Sep 2011 16:20:25 -0400

Hey Russ,
My principal interest was to have a reference for policy regarding key replacement.
But I am always for as many references as relevant.

Carter