Subject: Re: [Capwap] Proposed resolution for Issue 226

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 30 Nov 2006 06:53:19 -0800

Thanks for your comments. I will wait for your complete response before
digging deeper. However, I do want to note that I have issues with the
proposal you prefer. The CAPWAP protocol really has no way to know (nor
should it) the internal mechanics of the DTLS stack. The whole reason
for wanting to use a standards based crypto algorithm was to be able to
leverage from the community review and availability of these stacks. If
I utilize openSSL, my capwap stack doesn't really understand how the
states change internally to DTLS - nor should it. I really believe that
CAPWAP must be very explicit in what notifications it needs, and how it
needs to interact with the stack. However, I don't believe the
specification needs to expand any further into areas that in some cases
it is unable to detect.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Scott Kelly [mailto:[email-masked]] 
> Sent: Thursday, November 30, 2006 5:54 AM
> To: Pat Calhoun (pacalhou)
> Cc: capwap
> Subject: Re: [Capwap] Proposed resolution for Issue 226
> 
> Hi Pat,
> 
> Comments inline below (with much text trimmed)...
> 
> Pat Calhoun (pacalhou) wrote:
> > All,
> > 
> > At the meeting in San Diego, there seemed to be general 
> agreement that 
> > it was unnecessary to describe the DTLS state machine within the 
> > CAPWAP specification. I presented an overview of the changes that 
> > would be required, and this e-mail contains the actual 
> proposed text 
> > that I would like to submit to the list.
> 
> I don't think we had general agreement on the semantic point. 
> I think we agreed at the meeting to take the discussion to the list.
> 
> > NOTE: This is unfortunately, a rather lengthy e-mail. I 
> have decided 
> > to include complete state machine text as opposed to snippets, 
> > otherwise it makes it rather difficult to really understand 
> the proposal.
> > 
> > 
> > 2.3.  CAPWAP State Machine Definition
> > [...]
> >        /==============>=====================\
> >        "                                    "
> >        "  /==========<===============\      "
> >        "  "                          "t     v
> >        "  "   
> +-----------------------------------------------------+
> >        "  "   |                       DTLS                  
>         |
> >        "  "   
> +-----------------------------------------------------+
> >        "  "   ^   "p              ^                        
> ^        DTLS
> >        "  
> ~~~~"~~~"~~~~~~~~~~~~~~~"~~~~~~~~~~~~~~~~~~~~~~~~"~~~~~~~~~~~~
> >        "  "   "   "               "                        
> "      CAPWAP
> >        "  "   "   "               "                        "
> >        "  "   "   "   /-----------+---<-----------+        "
> >        "  "  q"   v   v           "r              |d       "
> >        "  "  +--------+  b+-----------+    +----------+    "
> >        ^  v  |  Idle  |-->| Discovery |--->|  Sulking |    "
> >        "  "  +--------+ a +-----------+ c  +----------+    "
> >        "  "                 |e            /----------------+-----\
> >        "  "                 |             |                "u    |
> >        "  "                 |    +----------+ o+-------------+   |
> >        "  "                 |    |   Run    |->|    Reset    |   |
> >        "  "                 |   n+----------+  +-------------+   |
> >        "  "                 |         ^         ^       ^        |
> >        "  "                 |         |   /-----/       |        |s
> >        "  "                 v        m|  k|             |l       v
> >        "  \==>+--------------+  +------------+ I      
> +------------+j
> >        "      |    Join      |->|  Configure |------->| Image Data |
> >        \======+--------------+ g+------------+        +------------+
> >              f
> > 
> >                  Figure 3: CAPWAP Integrated State Machine
> > 
> 
> I don't have time to give this the full treatment it deserves 
> this morning, but I'll give a brief response now, and follow 
> up within the next few days with additional detail if 
> necessary. The short of it: 
> we've agreed that the rekey state can be removed, and after 
> mulling this over in depth, I think we can collapse the idle 
> and init portions of the dtls state diagram into one box if 
> people really deem this critical, but I think we need the others.
> 
> The current dtls portion of the state diagram is conceptual, 
> and does not specify explicit dtls protocol states. Rather, 
> it specifies critical interactions between the dtls module 
> (hardware, library, or
> roll-yer-own) and the capwap state machine at various points 
> in the dtls session initialization, establishment, running, 
> and tear-down phases. 
> I'm not sure why you object to a diagram that helps 
> implementers get critical implementation details right.
> 
> Charles and I discussed this at length in San Diego, and I 
> also spoke with others in the security community. The capwap 
> implementation must exert control over the dtls 
> implementation at critical points in the dtls interaction. In 
> particular, capwap must be able to
> 
> 1) kick dtls into a protocol initiation phase (or prevent it 
> from entering one)
> 
> 2) there must be an explicit call-out from dtls to capwap for 
> authorization prior to completion of the handshake. This is a 
> hard requirement. This doesn't imply you couldn't preload the 
> cert/key for a given session, but a nominally correct 
> specification must explicitly designate this call-out.
> 
> 3) it is conceptually useful to illustrate the shutdown phase
> 
> Again, these are conceptual phases in dtls session 
> management, and while there is clear interaction with the 
> underlying dtls protocol state machine, it is not our intent 
> to specify that state machine here. If language making that 
> more clear would help, I'd be happy to try to craft some.
> 
> I think the diagram you sent in the previous email (repeated 
> below) is the one we should use, perhaps with minor 
> modification. If people feel very strongly I guess we can 
> collapse the idle/init boxes into one init box, but I think 
> that's the most minimalistic presentation that still captures 
> the critical interactions.
> 
>              /-------------<----------------+--------------------\
>              v                              |d                   |
>           +------+  b+-----------+    +----------+               |
>           | Idle |-->| Discovery |--->|  Sulking |               |
>           +------+ a +-----------+ c  +----------+               |
>            ^   |aa    ^ |e            /----------------------\   |
>            |   V     f| v            k|                      |   |
>         h +--------------+  +------------+ i +------------+j |   |
>        /--|    Join      |->|  Configure |-->| Image Data |  |   |
>        |  +--------------+ g+------------+   +------------+  |   |
>        |   "c1,  ^  ^   ^        m|            ^    |l       |   |
>        |   "c4   "  "   "         |    /-------/    |   /----/   |
>        |   "     "  "   "         V    |s           v   V        |
>        |   "     "  "   "   +------------+ o+------------+       |
>        |   "     "  "   "   |    Run     |->|    Reset   |-------/
>        |   "     "  "   "  n+------------+  +------------+   p
>        |   "     "  "   "        "c2  ^       ^  c3"   ^
>        \---"-----"--"---"--------"----"-------/    "   "     CAPWAP
>     ~~~~~~~"~~~~~"~~"~~~"~~~~~~~~"~~~~"~~~~~~~~~~~~"~~~"~~~~~~~~~~~~
>            "     "  "   "        "    "            "   "      DTLS
>            v     "  "n2 \"""""\  "    "            v   "n6,n7
>     /-->+------+ " W+------+  "  "    "      +------------+
>     | /-| Idle | " C| Auth |--"~-"----"----->|  Shutdown  |-------\P
>     | | +------+ "  +------+V "  "    " /--->|            |<----\ |
>     | |X     Z|  "   ^  U|    "  " n4 " |    +------------+     | |
>     | |       |  "   |   |    "  " n5," |                       | |
>     | |       v  "n1 |Y  |  n3"  v  n8" |R                      | |
>     | |      +--------+  |  +------------+                      | |
>     | |      |  Init  |  \->|    Run     |                    
>   | | <<=
> NOTE REMOVAL OF REKEY STATE
>     | |      +--------+     |            |                      | |
>     | |                     +------------+                      | |
>     | \---------------------------------------------------------/ |
>     \-------------------------------------------------------------/
> 
> 
> (I haven't edited this to collapse the idle/init states, but 
> that could easily be done for the document if deemed important).
> 
> We went through discussions like this in IPsec. Some people 
> thought specification of detailed packet processing and 
> application of associated policy were overly prescribed. 
> However, many of us agreed that explicitly detailing complex 
> security interactions is important, and that's what you'll 
> find in the current specs.
> 
> We also noted that people are free to implement things 
> internally as they see fit. Anything which does not impact 
> interoperability is fair game in your implementation. 
> However, we, as specification writers, should provide a 
> nominally correct implementation specification, and make 
> clear the security implications of deviation at critical points.
> 
> Scott
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 30 Nov 2006 08:39:21 -0800 (GMT-08:00)

Hi Pat,

> From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
> Sent: Thursday, November 30, 2006 6:53 AM
> To: Scott Kelly
> Cc: capwap
> Subject: RE: [Capwap] Proposed resolution for Issue 226
> 
> digging deeper. 

I should have deleted the part saying I wasn't giving it the treatment it deserved once I got around to proof-reading, because in the end, I think I did.

> However, I do want to note that I have issues with the
> leverage from the community review and availability of these 
> stacks.

I think you're missing the primary support for using a standards-based crypto algorithm. It is not so that we can ignore security. I think we gave ample explanation for this long ago on this very list, so I won't go through it again here - you can go back and review this if you don't remember.

CAPWAP must have clear explicit knowledge of the security mechanism it is applying, be it DTLS, IPsec, or whatever. 

>If

This isn't really very different from what I said. The fact is that OpenSSL and other (D)TLS libraries provide API hooks for everything in the current CAPWAP state machine description, and I think any reasonable implementation would do the same. Exactly what is about the diagram that bothers you so much? 

Scott

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 30 Nov 2006 08:52:27 -0800

> CAPWAP must have clear explicit knowledge of the security 
> mechanism it is applying, be it DTLS, IPsec, or whatever. 

Wasn't arguing this case.

> This isn't really very different from what I said. The fact 
> is that OpenSSL and other (D)TLS libraries provide API hooks 
> for everything in the current CAPWAP state machine 
> description, and I think any reasonable implementation would 
> do the same. Exactly what is about the diagram that bothers 
> you so much? 

Because it implies that the CAPWAP stack must ensure the DTLS stack
transition states, and this is in a normative section of the document.
Issue 226 was around the fact that the CAPWAP stack did not have ample
visibility into the actual DTLS control packets to be able to comply to
the state machine defined in the spec. As you've mentioned as well, this
is all conceptual, and the inner workings of the DTLS stack really has
no impact to the CAPWAP protocol itself - as long as the configuration
(e.g., crypto algorithms), triggers and APIs we've defined in the spec
are available.

Pat Calhoun

> From: Scott G. Kelly [mailto:[email-masked]] 
> Sent: Thursday, November 30, 2006 8:39 AM
> To: capwap; Pat Calhoun (pacalhou)
> > Thanks for your comments. I will wait for your complete response 
> > before digging deeper.
> 
> I should have deleted the part saying I wasn't giving it the 
> treatment it deserved once I got around to proof-reading, 
> because in the end, I think I did.
> 
> > However, I do want to note that I have issues with the proposal you 
> > prefer. The CAPWAP protocol really has no way to know (nor 
> should it) 
> > the internal mechanics of the DTLS stack. The whole reason 
> for wanting 
> > to use a standards based crypto algorithm was to be able to 
> leverage 
> > from the community review and availability of these stacks.
> 
> I think you're missing the primary support for using a 
> standards-based crypto algorithm. It is not so that we can 
> ignore security. I think we gave ample explanation for this 
> long ago on this very list, so I won't go through it again 
> here - you can go back and review this if you don't remember.
> 
> 
> >If
> >states change internally to DTLS - nor should it. I really  believe 
> >that  CAPWAP must be very explicit in what notifications it 
> needs,  and 
> >how it  needs to interact with the stack. However, I don't 
> believe the  
> >specification needs to expand any further into areas that in  some 
> >cases  it is unable to detect.
> 
> 
> Scott
>

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 30 Nov 2006 09:26:11 -0800 (GMT-08:00)

Hi Pat,

-----Original Message-----
>From: "Pat Calhoun (pacalhou)" <[email-masked]>
>Sent: Nov 30, 2006 8:52 AM
>To: "Scott G. Kelly" <[email-masked]>, capwap <[email-masked]>

I guess this is where email begins to fail us as a communication tool, or maybe I was just not explicit enough. You seem to be saying "wasn't arguing the case, but here's my argument:...".  Maybe I'm missing something here, but I'm confused.

The blocks in the diagram are conceptual - if you look at the dtls and tls rfc's, you won't see these states. However, the blocks do represent explicit phases which map onto pretty much any interoperable dtls state machine, and in fact, we *do* want to normatively say that certain things must happen with certain types of dtls/capwap synchronization in order for the security properties we intend to design in to hold. 

For example, when the server (the AC) DTLS implementation receives the client cert, it (nominally) must call-out to the capwap implementation to say, "is this identity okay?" before proceeding. This is a hard requirement. The diagram illustrates this. Likewise, when the server receives a valid ClientHello, it is CAPWAP that must decide whether or not to respond (otherwise, how does CAPWAP implement DoS rate limiting?)

Again, I don't understand your concern. You have to implement these APIs, and above you seem to indicate you recognize this and you are okay with it. Why waste time arguing about the picture?

Scott

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 30 Nov 2006 10:39:20 -0800

The good news is that I don't think we are really that far apart.

> The blocks in the diagram are conceptual - if you look at the 
> dtls and tls rfc's, you won't see these states. However, the 
> blocks do represent explicit phases which map onto pretty 
> much any interoperable dtls state machine, and in fact, we 
> *do* want to normatively say that certain things must happen 
> with certain types of dtls/capwap synchronization in order 
> for the security properties we intend to design in to hold. 

But do we agree that the CAPWAP protocol has no way to know when the
DTLS state machine moves from state 'A' to 'B', and since this is not
even described in the (d)tls specs, then what exactly does it mean to
the reader? If these states are purely conceptual, then I believe they
provide no value. The fact that a compliant DTLS session must provide
certain inputs and outputs seems sufficient to me.

> For example, when the server (the AC) DTLS implementation 
> receives the client cert, it (nominally) must call-out to the 
> capwap implementation to say, "is this identity okay?" before 
> proceeding. This is a hard requirement. The diagram 
> illustrates this. 
Not really, I don't see that in the spec. What I would MUCH prefer to
see is a NEW notification from DTLS to CAPWAP to allow the CAPWAP to
receive the peer's credentials, and (optionally) perform an
authorization check. This is not there today, so I would welcome a new
issue on this topic.

> Likewise, when the server receives a valid 
> ClientHello, it is CAPWAP that must decide whether or not to 
> respond (otherwise, how does CAPWAP implement DoS rate limiting?)
So this requires parsing of the DTLS packets by CAPWAP... I believe
there is another option, which I plan to address. The sulking state has
never progressed properly from its original intent to be optimized for
use with DTLS. We need to introduce a new counter FailedDTLS. This
counter is increased everytime a DTLS session setup fails (via the
notification). When the counter reaches a threshold, the state machine
hits the sulking state. When a successful DTLS session is established,
the counter is cleared.

> 
> Again, I don't understand your concern. You have to implement 
> these APIs, and above you seem to indicate you recognize this 
> and you are okay with it. Why waste time arguing about the picture?

My issue is that if we introduce these blocks in the state machine, we
pretty much have to define the state transitions. This is a DTLS
problem, not a CAPWAP one. That said, if we need to split it up into two
to introduce authorization, then I'm ok with that.

Pat Calhoun