Capwap Mailing List: Re: Issue 37: Key Rollover issue

[Pat Calhoun (pacalhou) (pcalhoun]

Scott has recommended that we remove the following sentence from
paragraph 2 of section 12.6: 

"At a minimum, devices SHOULD use SSH-style certificate caching to
guarantee consistency."

Any disagreements?

PatC
 

-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Tuesday, February 12, 2008 9:17 PM
To: Sam Hartman
Cc: capwap [at] frascone.com
Subject: Re: [Capwap] Issue 37: Key Rollover issue

Scott, do you have any text that could handle Sam's issue?

PatC 

-----Original Message-----
From: Sam Hartman [mailto:hartmans-ietf [at] mit.edu]
Sent: Thursday, January 03, 2008 5:27 AM
To: Pat Calhoun (pacalhou)
Cc: capwap [at] frascone.com
Subject: Re: Issue 37: Key Rollover issue

>>>>> "Pat" == Pat Calhoun (pacalhou) <pcalhoun [at] cisco.com> writes:

    Pat> Sam, This is a topic that has already been raised and
    Pat> closed. I am including part of an e-mail exchange on the list
    Pat> where this was discussed. I can also point you to
    Pat> http://www.capwap.org/cgi-bin/roundup.old/CAPWAP/issue228,
    Pat> which is the old tracker entry where more information can be
    Pat> found.

    Pat> I would like to close this issue, as it is redundant, but
    Pat> want to make sure you are ok with it first.

As best I can tell, the old issue you refer me to is a question about
whether to rekey the DTLS session keys within a single active capwap
session.
(Session may be the wrong term for your protocol, but I hope I am
sufficiently clear)

I agree with the WG's decision on that issue.


However I think I was describing a different issue.  I was discussing
the rollever of public keys in certificates used in leap of faith
transactions.


The reason a site would want to roll over these keys is more about staff
changes and AC replacement than cryptographic limitations.



So, I think the issue I raise is different and at least requires
security considerations text.  It concerns me because without clear
guidance you can get into a situation where you cannot rekey either when
you have a key compromise or when you have staffing changes because some
of your equipment is implementing a primitive leap of faith strategy
similar to ssh.


I'm not entirely sure what the anser is, but I am sure that the problem
is real.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap