Subject: Re: [Capwap] Proposed Resolution for Issue 127: Use of Session ID

From: Charles Clancy <[email-masked]>
Date: Fri, 01 Dec 2006 17:08:47 -0500

Promised text for the security considerations of the base spec is below.

   Since DTLS does not export a unique session identifier, there can be
   no explicit protocol binding between the DTLS layer and CAPWAP layer.
   As a result, implementations MUST provide a mechanism for performing
   this binding.  For example, an AC MUST NOT associate decrypted DTLS
   control packets with a particular WTP session based solely on the
   Session ID in the packet header.  Instead, identification should be
   done based on which DTLS session decrypted the packet.  Otherwise one
   authenticated WTP could spoof another authenticated WTP by altering
   the Session ID in the encrypted CAPWAP header.

   It should be noted that when the CAPWAP data channel is unencrypted,
   the WTP Session ID is exposed and possibly known to adversaries and
   other WTPs.  This would allow the forgery of the source of
   data-channel traffic.  This, however, should not be a surprise for
   unencrypted data channels.  When the data channel is encrypted, the
   Session ID is not exposed, and therefore can safely be used to
   associate a data and control channel.  The 64-bit length of the
   Session ID mitigates online guessing attacks where an adversarial,
   authenticated WTP tries to correlate his own data channel with another
   WTP's control channel.  Note that for encrypted data channels, the
   Session ID should only be used for correlation for the first packet
   immediately after the initial DTLS handshake.  Future correlation
   should instead be done via identification of a packet's DTLS session.

-- 
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy

Pat Calhoun (pacalhou) wrote:
> ok - I will make the necessary change and incorporate your text once you
> send it to me.
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> 
>  
> 
>> -----Original Message-----
>> From: Charles Clancy [mailto:[email-masked]] 
>> Sent: Thursday, November 30, 2006 4:23 AM
>> To: Pat Calhoun (pacalhou)
>> Cc: [email-masked]
>> Subject: Re: [Capwap] Proposed Resolution for Issue 127: Use 
>> of Session ID
>>
>> I agree with keeping the Session ID.  However, I think its 
>> length should be increased to at least 64 bits to make it 
>> difficult to guess if both control and data channels are encrypted.
>>
>> I think we also need some text in the security considerations 
>> section about bindings between the DTLS and CAPWAP layers.  
>> Since the DTLS API doesn't export a session ID for us to use, 
>> implementations will need to be sure some unique identifier 
>> is available to associate decrypted CAPWAP packets with the 
>> correct WTP session at the AC.  The session ID in the CAPWAP 
>> header is not bound to DTLS in any way, so it is by itself 
>> insufficient.  I wrote some text after the IETF... I'll try 
>> and dig it up.
>>
>> --
>> t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy
>>
>> Pat Calhoun (pacalhou) wrote:
>>> All,
>>>
>>> Following the proposal made at the IETF meeting in San 
>> Diego, please 
>>> find below the proposed text for the handling of this issue:
>>>
>>> 4.2.  CAPWAP Header
>>>
>>> [...]
>>>
>>>         0                   1                   2           
>>         3
>>>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
>> 6 7 8 9 0 1
>>>        
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>        |Version|   RID   |  HLEN   |  WBID   |T|F|L|W|M|    
>>  Flags     |
>>>        
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>        |          Fragment ID          |     Frag Offset    
>>      |Rsvd |
>>>        
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>        |                          Session ID                
>>            |
>>>        
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>        |                 (optional) Radio MAC Address       
>>            |
>>>        
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>        |            (optional) Wireless Specific 
>> Information           |
>>>        
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>        |                        Payload ....                
>>            |
>>>        
>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>> [...]
>>>    Session ID:  The 32-bit field contains a pseudo-random session
>>>       identifier thatis used to help match control frames with data
>>>       frames.  The use of the Session ID field is further 
>> described in
>>>       Section 6.1.
>>> [...]
>>>
>>> 5.1.  Discovery Request Message
>>> [...]
>>>    The Discovery Request message may be sent as a unicast, 
>> broadcast or
>>>    multicast message.  The Session ID field in the CAPWAP 
>> Header MUST be
>>>    set to zero as it is unused in all Discovery messages.
>>>
>>> [...]
>>> 5.2.  Discovery Response Message
>>> [...]
>>>
>>>    The Discovery Response message is sent by an AC after receiving a
>>>    Discovery Request message from a WTP.  As with the 
>> Discovery Request,
>>>    the Session ID field in the CAPWAP header MUST be set to zero.
>>> [...]
>>>
>>> 6.1.  Join Request
>>> [...]
>>>
>>>    The WTP includes a pseudo-random 32 bit Session ID in the CAPWAP
>>>    Header (see Section 4.2).  The Session ID MUST remain 
>> the same across
>>>    all future CAPWAP control and data packets sent by both 
>> the WTP and
>>>    the AC to identify the specific CAPWAP session.  The WTP 
>> and AC MUST
>>>    ensure that all future packets received with the same 
>> Session ID have
>>>    the same source IP Address and UDP Port Number.
>>> [...]
>>> 11.  NAT Considerations
>>>
>>> [...]
>>>
>>>    It is, however, possible for two or more WTPs to reside 
>> behind the
>>>    same NAT system.  In this instance, the AC would receive multiple
>>>    connection requests from the same IP address, and could end up
>>>    thinking all of the connection requests come from the 
>> same WTP.  It
>>>    is important that the AC not disconnect another WTP's 
>> session as a
>>>    result of this situation occuring.  Therefore, the AC 
>> should consider
>>>    the WTP's identity, which is communicated within the 
>> DTLS exchange
>>>    used to secure the CAPWAP control channel.  The CAPWAP header
>>>    includes a Session Identifier field, which is used to match the
>>>    control and data plane.  This allows the AC to match the 
>> control and
>>>    data plane flows from multiple WTPs behind the same NAT system
>>>    (therefore all sharing the same IP address).
>>>
>>>
>>> Pat Calhoun
>>> CTO, Wireless Networking Business Unit Cisco Systems 
>>> _________________________________________________________________
>>> To unsubscribe or modify your subscription options, please visit:
>>> http://lists.frascone.com/mailman/listinfo/capwap
>>>
>>> Archives: http://lists.frascone.com/pipermail/capwap

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

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