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

[Pat Calhoun (pacalhou) (pcalhoun]

All,

The editors, security advisors, chairs and ADs met yesterday to get
through these last security related issues, and agreed on a fix for this
issue. In addition to the removal of the sentence below, we agreed that
some level of pre-provisioning is required on both the WTP and the AC to
allow for the DTLS session setup. There was general agreement that in
this version of the protocol we would simply address it through text,
but that some protocol related effort should be tackling this issue.
Some folks felt this should be addessed in the CAPWAP protocol.

I am including the proposed text here. As an aside, this text also
resolves issue 36.

<text>
12.5.  CAPWAP Pre-Provisioning

   In order for CAPWAP to establish a secure communication with a peer,
   some level of pre-provisioning on both the WTP and AC is necessary.
   This section will detail the minimal number of configuration
   parameters.

   When using preshared keys, it is necessary to configure the preshared
   key for each possible peer with which a DTLS session may be
   established.  To support this mode of operation, one or more entries
   of the following table may be configured on either the AC or WTP:

   o  Identity: The identity of the peering AC or WTP.  This format MAY
      be either in the form of an IP address or host name (the latter of
      which needs to be resolved to an IP address using DNS).

   o  Key: The pre-shared key for use with the peer when establishing
      the DTLS session (see Section 12.6 for more information).

   o  Key Identifier: The pre-shared key identifier, as described in RFC
      4279 [RFC4279].

   When using certificates, the following items need to be pre-
   provisioned:

   o  Device Certificate: The local device's certificate (see
      Section 12.7 for more information)

   o  Trust Anchor: Trusted root certificate chain used to validate any
      certificate received from CAPWAP peers.  Note that one or more
      root certificate MAY be configured on a given device.

   Regardless of the authentication method, the following items need to
   be pre-provisioned:

   o  Access Control List: The access control list table contains the
      identities of one or more CAPWAP peers, along with a rule.  The
      rule is used to determine whether communication with the peer is
      permitted (see Section 2.4.4.3 for more information).
</text>

Comments?

PatC 

-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Thursday, February 14, 2008 2:58 PM
To: Pat Calhoun (pacalhou); Sam Hartman
Cc: capwap [at] frascone.com
Subject: RE: [Capwap] Issue 37: Key Rollover issue

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