Subject: Re: [Capwap] Issue 34: keyPurposeID needs clarification

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 10 Mar 2008 12:17:33 -0700

All,

The editors, security advisors, chairs and ADs met today at lunch and
discussed this topic. We agreed on an approach, which I believe is
represented in the following text:

<text>
   If a device presents its certificate which includes either the id-kp-
   capwapAC or id-kp-capwapWTP EKU, its role MUST be enforced.  For
   instance, if a certificate received during a DTLS session
   establishment includes the id-kp-capwapAC EKU, the receiving CAPWAP
   device MUST NOT allow its peer to act as a WTP.  In the absence of
   either one of these EKUs, the id-kp-anyExtendedKeyUsage EKU allows a
   device to act as either a WTP or AC.
</text>

Comments?

PatC 

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Monday, March 10, 2008 5:28 AM
To: Pat Calhoun (pacalhou)
Cc: capwap
Subject: Re: [Capwap] Issue 34: keyPurposeID needs clarification

>>>>> "Pat" == Pat Calhoun (pacalhou) <[email-masked]> writes:

    Pat> Sam,
    Pat> Would you accept some text that simply states that the Any
KeyPurposeID
    Pat> SHOULD be ignored?

Yes, although I'd like to understand why you believe that's the right
answer.  That's sort of the opposite answer most people give.  But if
you've thought it through and believe that's the right answer that would
respond to my issue.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 10 Mar 2008 14:56:26 -0700

Works for me.

PatC 

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Monday, March 10, 2008 1:59 PM
To: Pat Calhoun (pacalhou)
Cc: capwap
Subject: Re: [Capwap] Issue 34: keyPurposeID needs clarification

>>>>> "Pat" == Pat Calhoun (pacalhou) <[email-masked]> writes:

    Pat> All,
    Pat> The editors, security advisors, chairs and ADs met today at
lunch and
    Pat> discussed this topic. We agreed on an approach, which I believe
is
    Pat> represented in the following text:

    Pat> <text>
    Pat> If a device presents its certificate which includes either the
id-kp-
    Pat> capwapAC or id-kp-capwapWTP EKU, its role MUST be enforced.
For
    Pat> instance, if a certificate received during a DTLS session
    Pat> establishment includes the id-kp-capwapAC EKU, the receiving
CAPWAP
    Pat> device MUST NOT allow its peer to act as a WTP.  In the absence
of
    Pat> either one of these EKUs, the id-kp-anyExtendedKeyUsage EKU
allows a
    Pat> device to act as either a WTP or AC.
    Pat> </text>

The EKU extension is defined in such a way that if a device presents
both keyPurposeIDs then the device is permitted to take on either role.

I'd say something like
[I'm not looking at RFC 3280, so please double check my capitalization]

All capwap devices MUST support the ExtendedKeyUsage certificate
extension if it is present in a certificate.  If the extension is
present, then the certificate MUST have either the id-kp-
   capwapAC or the id-kp-anyExtendedKeyUsage  keyPurposeID to act as an
AC.  Similarly, if the extension is present, a device must have the
id-kp-capwapWTP or id-kp-anyExtendedKeyUsage  keyPurposeID to act as a
WTP.

--------------------

As a note, the extension is called EKU, but the extension contains
multiple keyPurposeIDs

---

From: Sam Hartman <[email-masked]>
Date: Mon, 10 Mar 2008 16:59:03 -0400

>>>>> "Pat" == Pat Calhoun (pacalhou) <[email-masked]> writes:

    Pat> All,
    Pat> The editors, security advisors, chairs and ADs met today at lunch and
    Pat> discussed this topic. We agreed on an approach, which I believe is
    Pat> represented in the following text:

    Pat> <text>
    Pat> If a device presents its certificate which includes either the id-kp-
    Pat> capwapAC or id-kp-capwapWTP EKU, its role MUST be enforced.  For
    Pat> instance, if a certificate received during a DTLS session
    Pat> establishment includes the id-kp-capwapAC EKU, the receiving CAPWAP
    Pat> device MUST NOT allow its peer to act as a WTP.  In the absence of
    Pat> either one of these EKUs, the id-kp-anyExtendedKeyUsage EKU allows a
    Pat> device to act as either a WTP or AC.
    Pat> </text>

The EKU extension is defined in such a way that if a device presents
both keyPurposeIDs then the device is permitted to take on either
role.

I'd say something like

All capwap devices MUST support the ExtendedKeyUsage certificate
extension if it is present in a certificate.  If the extension is
present, then the certificate MUST have either the id-kp-
   capwapAC or the id-kp-anyExtendedKeyUsage  keyPurposeID to act as an AC.  Similarly, if the extension is present, a device must have the id-kp-capwapWTP or id-kp-anyExtendedKeyUsage  keyPurposeID to act as a WTP.

--------------------

As a note, the extension is called EKU, but the extension contains multiple keyPurposeIDs

---

From: Sam Hartman <[email-masked]>
Date: Mon, 10 Mar 2008 08:28:13 -0400

>>>>> "Pat" == Pat Calhoun (pacalhou) <[email-masked]> writes:

    Pat> Sam,
    Pat> Would you accept some text that simply states that the Any KeyPurposeID
    Pat> SHOULD be ignored?

Yes, although I'd like to understand why you believe that's the right
answer.  That's sort of the opposite answer most people give.  But if
you've thought it through and believe that's the right answer that
would respond to my issue.