Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

From: "T Sridhar" <[email-masked]>
Date: Fri, 22 Sep 2006 15:18:16 -0700

Hi,

It would be good to get a summary of the reasons why this proposal

should be accepted or rejected. Currently we have a number of email

threads on this topic but a summary would be great. Saravanan/Pat -

could you folks help?

Thanks,

Sridhar

-----Original Message-----

From: Margaret Wasserman [mailto:[email-masked]] 

Sent: Friday, September 22, 2006 3:12 PM

To: [email-masked]

Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i Considerations

Hi All,

I'm trying to get a read on whether this issue needs further  

discussion or not...

Saravanan has made a proposal for change to the specification, and he  

has offered an explanation for the motivation behind this proposal  

(see below).

Pat Calhoun has argued that this level of flexibility is unnecessary  

and that the specification fully supports IEEE 802.11i and meets the  

requirements, as written.

I've seen a few notes in support of Pat's position and I haven't  

noticed anyone else supporting Saravanan's proposal.  If there are  

others who support Saravanan's proposal, please speak up.  Unless we  

see strong support for this proposal, we'll have to conclude that the  

WG does not have consensus to make this change.

Margaret

On Sep 22, 2006, at 5:03 AM, Saravanan Govindan wrote:

> Hi Margaret,

> Thank you for reviewing the discussion on this issue.

> The issue here is the working of IEEE 802.11i when the 802.11i

> authenticator element is at the AC and the 802.11i crypto element  

> is at

> the WTP. Particularly, it is for the 4-way handshake between

> authenticator and supplicant.

> Now, the 4-way handshake requires knowing the value of KeyRSC sequence

> counter. The KeyRSC helps both authenticator and supplicant keep track

> of their exchanges. It serves to protect against threats by tracking

> sequential frames. The KeyRSC is maintained at the at the point of

> encryption, i.e. just before transmission over the wireless channel.

> In the case of CAPWAP, the 4-way handshake is between the AC

> (authenticator) and the wireless station (supplicant).

> The problem arises, when the authenticator is at the AC and the crypto

> element (together with KeyRSC) is at the WTP. This is a fairly common

> design. Now in this case, the AC starts the 4-way handshake but it  

> does

> not know the value of the KeyRSC. The KeyRSC is maintained by the WTP.

> Based on this, the current CAPWAP specification does not allow for  

> a way

> to conduct the 4-way handshake with the correct KeyRSC.

> The functionality I would like to see is a way for the authenticator

> (AC) to use the correct prevailing value of KeyRSC (maintained by the

> WTP) in its 4-way handshake.

> One way to introduce this functionality in to CAPWAP is to have  

> part of

> the 4-way handshake be sent from AC to WTP. This will allow the 4-way

> handshake to use the correct value of the KeyRSC before being sent to

> the wireless station.

> I hope this helps clarify my view on the issue.

> Cheers,

> Saravanan

> -----Original Message-----

> From: Margaret Wasserman [mailto:[email-masked]]

> Sent: Thursday, September 21, 2006 8:26 PM

> To: Saravanan Govindan

> Cc: Pat Calhoun (pacalhou); [email-masked]

> Subject: Re: [Capwap] Issue 43 - Explanation for 802.11i  

> Considerations

> Hi again,

> Okay, I am even more confused than I thought I was...

> Saravanan, you wrote:

> On Sep 17, 2006, at 10:24 PM, Saravanan Govindan wrote:

>> Pat,

>> The issue here is about how 802.11i exchanges are done when

>> authenticator is at the AC and crypto elements are at the WTP.  

>> This is

>> the requirement.

> And, in response, Pat Calhoun wrote:

> On Sep 18, 2006, at 4:15 PM, Pat Calhoun (pacalhou) wrote:

>> The current specification allows the authenticator to reside in the

>> AC,

>> while the data packet crypto elements in the WTP. This feature is

>> already in the specification.

> Pat's message matches my reading of the specification.

> So, Saravanan, what functionality are you asking for that is not

> already supported by the specification?  And why do you think it is

> necessary?  it will not be helpful to my understanding to re-send

> your proposal or to cite the requirements document...  Please

> summarize what functionality you think is missing from the current

> specification and why you think that functionality is necessary to

> support IEEE 802.11i or any important use case.

> At some point, the chairs may need to make a consensus call on this

> issue, and I'd like to understand your view and make sure that it has

> been clearly communicated to the WG before we ask the WG to decide on

> this issue.

> Thanks,

> Margaret

_________________________________________________________________

To unsubscribe or modify your subscription options, please visit:

http://lists.frascone.com/mailman/listinfo/capwap

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

Legal Disclaimer:

The information contained in this message may be privileged and confidential. It is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message

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

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

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 23 Sep 2006 09:35:48 -0400

Hi All,

[Pat and Saravanan, I have asked some questions of each of you  
below.  In particular, please note the request for more information  
at the end of the main message, before the beginning of the  
references section.]

At T. Sridhar's request, I'll attempt to summarize the discussion on  
this issue to date.

I realize that this is a _very_ long "summary".  Sadly, it may  
actually be longer than the discussion that it is attempting to  
summarize...  However, if you take the time to read this message, I  
think that we may be able to reach a good, shared understanding of  
this issue, which may help us to make a wise and well-informed decision.

First, let me point out the relevant portions of the CAPWAP-related  
documents...

== RFC 4564, Section 5.1.10, "IEEE 802.11i Considerations" ==

This section describes the CAPWAP protocol security requirements  
related to IEEE 802.11i.  It is included under the "Mandatory and  
Accepted Objectives" section.  The full text of this section is  
included below for reference.

The normative text in this section states:

    "The CAPWAP protocol MUST determine the exact structure of the
    centralized WLAN architecture in which authentication needs to be
    supported, i.e., the location of major authentication components.
    This may be achieved during WTP initialization where major
    capabilities are distinguished.

    The protocol MUST allow for the exchange of key information when
    authenticator and encryption roles are located in distinct  
entities."

In the discussion portion of this section, there is a reference to  
the "Architecture Taxonomy" document, RFC 4118, and there is an  
indication that CAPWAP must support the variants described in that  
document.

In summary, this section places two requirements on the CAPWAP protocol:

1) The AC must be able to determine where the authentication and  
encryption functions reside.
(2) The protocol must support the transfer of key information if the  
authentication and encryption functions reside on different entities.

== RFC 4118, Section 5.8.1, "Client Data Security" ==

This section describes how 802.11 encryption and the 802.11x  
authenticator function can reside on different entities.  The full  
text of this section is included below for reference.

In summary, this section states that the termination point for "over  
the air" encryption may reside in either the WTP or the AC.  It also  
states that "in most cases" authentication will be performed by the  
AC.  If the encryption is terminated at the WTP, and authentication  
is performed on the AC, then the pair-wise transient key (PTK) needs  
to be transferred from the AC to the WTP over a secure channel.  It  
then goes on to discuss some key management issues.

== draft-ietf-capwap-protocol-specification-02.txt, Section 4.4.33,  
"WTP Descriptor" ==
== draft-ietf-capwap-protocol-specification-02.txt, Section 11.1.1,  
"Split MAC" ==
== draft-ietf-capwap-protocol-specification-02.txt,Section 11.1.2,  
"Local MAC" ==

Although authentication and encryption are mentioned in various  
places in the CAPWAP specification, I think it is possible to get an  
overview of the currently described functionality from reading the  
three sections listed above, all of which are included at the end of  
this message for reference.

The WTP Descriptor includes a field called "Encryption Capabilities"  
that allows the WTP to tell the AC whether or not it supports  
encryption, and to provide binding-specific information regarding  
what encryption capabilities are supported.  If a WTP supports  
encryption, the AC may (depending on AC configuration) choose to take  
advantage of that.

The Split MAC and Local MAC sections make it clear that both  
architectures support cases where encryption is supported on either  
the AC or the WTP, and they both include a provision for securely  
passing key information to the WTP when encryption is being performed  
there.

Now I'll offer my own interpretation of the above sections...

As indicated above, RFC 4564 places two requirements on the CAPWAP  
protocol:

1) The AC must determine where the authentication and encryption  
functions reside.
(2) The protocol must support the transfer of key information if the  
authentication and encryption functions reside on different entities.

Although the wording in the requirements document is quite abstract,  
the referenced Architecture Taxonomy makes it clear that we are  
really talking about cases where authentication resides on the AC and  
the encryption endpoint resides on either the WTP or the AC.  In any  
case, the requirements document does not seem to place a normative  
requirement on the CAPWAP specification to support specific  
configurations, merely for the AC to be able to determine the  
configuration in use, and for the protocol to be able to securely  
pass keys between the authenticator and the encryption endpoint if  
they reside on different entities.

The currently-defined CAPWAP protocol meets the first requirement by  
providing a mechanism for the AC to discover the encryption  
capabilities of the WTP and to then determine whether the encryption  
endpoint will be on the WTP or the AC.  In the CAPWAP protocol,  
authentication is always supported on the AC, so no mechanism is  
needed to discover/determine that.

The second requirement is met by the key transfer functions included  
in both the Split MAC and Local MAC architectures.

So, based on my interpretation, the current CAPWAP protocol document  
does attempt to meet both of the normative requirements from RFC 4564.

However, that doesn't mean that we can simply reject this issue,  
because Saravanan may actually be pointing out a technical flaw in  
the CAPWAP specification.

Saravanan has raised the point, which I don't believe is disputed,  
that the 4-way handshake will only work properly when the KeyRSC is  
located on the AC, not when the KeyRSC is located on the WTP.   
However, Saravanan claims that the KeyRSC will reside at the  
encryption endpoint (the WTP in this case), not at the authentication  
endpoint (the AC).  If Saravanan is correct, the current 4-way  
handshake described in the CAPWAP specification will not work  
properly, because the AC will lack the information necessary to  
generate the KeyMIC value that it is required to provide in message 3  
of the 4-way handshake.

Saravanan has made a specific proposal to correct this problem that  
calls for a modification to the CAPWAP specification that would  
support the case where the KeyRSC resides at the WTP.  For reference,  
I've included the full text of Saravanan's proposal at the end of  
this message.

== Saravanan's proposal ==

[Saravanan, please let me know if I am missing or misunderstanding  
anything here.]

In summary, Saravanan is proposing that we change how CAPWAP supports  
the IEEE 802.11i 4-way handshake to allow the AC to produce a nearly- 
complete EAPoL frame (containing everything but the KeyMIC value) and  
pass it to the WTP in a CAPWAP Key Configuration message.  The WTP  
would take then use the KeyRSC to generate the KeyMIC value, insert  
that value into the EAPoL frame and transmit the message (which is  
message 3 of the 4-way handshake) to the client.

== Pat's response ==

[Pat, please let me know if I am missing or misunderstanding anything  
here.]

Pat has argued that it is not necessary to support the case where the  
KeyRSC is maintained on the WTP.  Pat believes that is is possible  
for the encryption endpoint to reside on the WTP while the KeyRSC is  
maintained on the AC, and that we do not need to add additional  
options to the CAPWAP specification to support other cases.

I personally think that Saravanan and Pat may not be communicating  
successfully with each other, because Saravanan seems to be saying  
that the CAPWAP specification will not work as specified and needs to  
be changed in order to function properly, and Pat seems to think that  
Saravanan is trying to add an option to support an additional  
operating mode.  Am I misunderstanding something?

So, there seems to be at least one point of technical disagreement  
between Pat and Saravanan regarding where the KeyRSC will reside in  
the case where the authenticator is running on the AC and the  
encryption endpoint resides on the WTP.

Pat, could you provide some technical information that supports your  
position that the KeyRSC may reside on the AC, even when the  
encryption end-point is on the WTP?

Saravanan, could you provides some technical information that  
supports your position that the KeyRSC will reside on the WTP when  
the encryption end-point is on the WTP?

Margaret

---

REFERENCE MATERIALS:

== RFC 4564, Section 5.1.10, "IEEE 802.11i Considerations" ==

5.1.10.  IEEE 802.11i Considerations

    Classification: Operations

    Description:

    The CAPWAP protocol must support authentication in the centralized
    WLAN architecture in which the authenticator and encryption points
    can be located on distinct entities, i.e., WLAN controller or WTP.
    The Architecture Taxonomy illustrates a number of variants, in both
    local-MAC and split-MAC designs, in which the authenticator is
    located at the WLAN controller and the encryption points are at the
    WTPs.  The CAPWAP protocol must be applicable to these variants and
    allow authentication mechanisms and their constituent processes  
to be
    operable in these cases.

    An important issue to consider in this case is the exchange of key
    information when authenticator and encryption points are located on
    distinct entities.  For example, consider the case where IEEE  
802.11i
    is used in a WLAN in which the WLAN controller realizes the
    authenticator, some WTPs realize encryption (possibly local-MAC
    WTPs), and other WTPs rely on the WLAN controller for encryption
    (possibly split-MAC WTPs).

    Here, CAPWAP will first need to identify the location of the
    authenticator and encryption points between each WLAN controller-WTP
    pair.  This will likely be part of the initial WTP configuration.
    Subsequently, the WTPs that realize encryption will need CAPWAP to
    exchange key information with the authenticator at the WLAN
    controller.  For the WTPs that do not realize encryption, CAPWAP
    needs to adapt its control to bypass the key exchange phase.

    Clearly, the centralized WLAN architecture presents a different
    platform for authentication mechanisms compared to legacy WLANs in
    which a WTP realized both authenticator and encryption roles.  So
    this objective highlights the need for CAPWAP to support
    authentication and key management in the centralized WLAN
    architecture.

    Protocol Requirement:

    The CAPWAP protocol MUST determine the exact structure of the
    centralized WLAN architecture in which authentication needs to be
    supported, i.e., the location of major authentication components.
    This may be achieved during WTP initialization where major
    capabilities are distinguished.

    The protocol MUST allow for the exchange of key information when
    authenticator and encryption roles are located in distinct entities.

    Motivation and Protocol Benefits:

    The immediate focus of CAPWAP is on supporting IEEE 802.11-based
    WLANs.  As such, it is necessary for the protocol to recognize the
    major distinction in WLAN design with respect to IEEE 802.11i
    authenticator and encryption points.  This represents a significant
    variation that has been highlighted in the Architecture Taxonomy.
    The CAPWAP protocol benefits by accommodating such a major
    consideration from IEEE 802.11i.

    These requirements will be common for all authentication mechanisms
    over the centralized WLAN architecture.  So they are applicable to
    IEEE 802.11i, Universal Access Method (UAM), and other mechanisms.

    Relation to Problem Statement:

    The Problem Statement highlights the availability of different WTP
    designs and the need to ensure interoperability among them.  In this
    regard, operational changes occurring due to the separation of the
    IEEE 802.11i authenticator and encryption points need to be
    accommodated within the CAPWAP protocol.

== RFC 4118, Section 5.8.1, "Client Data Security" ==

5.8.1.  Client Data Security

    The survey shows clearly that the termination point for "over the
    air" 802.11 encryption [4] can be implemented either in the WTP  
or in
    the AC.  Furthermore, the 802.1X/EAP [6] functionality is  
distributed
    between the WTP and the AC where, in most cases, the AC performs the
    necessary functions as the authenticator in the 802.1X exchange.

    If the STA and AC are the parties in the 4-way handshake (defined in
    [4]), and 802.11i traffic encryption terminates at the WTP, then the
    Pairwise Transient Key (PTK) has to be transferred from the AC to  
the
    WTP.  Since the keying material is part of the control and
    provisioning of the WTPs, a secure encrypted tunnel for control
    frames is employed to transport the keying material.

    The centralized model encourages AC implementations to use one PMK
    for many different WTPs.  This practice facilitates speedy  
transition
    by an STA from one WTP to another that is connected to the same AC
    without establishing a separate PMK.  However, this leaves the  
STA in
    a difficult position, as the STA cannot distinguish between a
    compromised PMK and one that is intentionally being shared.  This
    issue must be resolved, but the resolution is beyond the scope of  
the
    CAPWAP working group.  The venue for this resolution is to be
    determined by the IEEE 802 and IETF liaisons.

    When the 802.11i encryption/decryption is performed in the AC, the
    key exchange and state transitions occur between the AC and the STA.
    Therefore, there is no need to transfer any crypto material between
    the AC and the WTP.

    Regardless of where the 802.11i termination point occurs, the
    Centralized WLAN Architecture records two practices for "over the
    wire" client data security.  In some cases there is an encrypted
    tunnel (IPsec or SSL) between the WTP and AC, which assumes that the
    security boundary is in the AC.  In other cases, an end-to-end
    mutually authenticated secure VPN tunnel is assumed between the
    client and AC, other security gateway, or end host entity.

== draft-ietf-capwap-protocol-specification-02.txt, Section 4.4.33,  
"WTP Descriptor" ==

4.4.33.  WTP Descriptor

    The WTP descriptor message element is used by a WTP to communicate
    it's current hardware/firmware configuration.  The value contains  
the
    following fields.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Max Radios  | Radios in use |    Encryption Capabilities    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Vendor Identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Type=0                 |             Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Value...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Vendor Identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Type=1                 |             Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Value...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Vendor Identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Type=0                 |             Length           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Value...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type:  33 for WTP Descriptor

    Length:  >= 31

    Max Radios:  An 8-bit value representing the number of radios (where
       each radio is identified via the RID field) supported by the WTP

    Radios in use:  An 8-bit value representing the number of radios
       present in the WTP

    Encryption Capabilities:  This 16-bit field is used by the WTP to
       communicate it's capabilities to the AC.  Since most WTP's  
support
       link layer encryption, the AC may make use of these services.
       There are binding dependent encryption capabilities.  A WTP that
       does not have any encryption capabilities would set this field to
       zero (0).  Refer to the specific binding for further  
specification
       of the Encryption Capabilities field.

    Vendor Identifier:  A 32-bit value containing the IANA assigned "SMI
       Network Management Private Enterprise Codes"

    Type:  The following values are supported.  The Hardware Version,
       Software Version, and Boot Version values MUST be included.

       0 - WTP Model Number:  The WTP Model Number MUST be included in
          the WTP Board Data message element.

       1 - WTP Serial Number:  The WTP Serial Number MUST be included in
          the WTP Board Data message element.

       2 - Board ID:  A hardware identifier, which MAY be included in  
the
          WTP Board Data mesage element.

       3 - Board Revision  A revision number of the board, which MAY be
          included in the WTP Board Data message element.

       4 - Hardware Version:  The WTP's hardware version number.

       5 - Software Version:  The WTP's Firmware version number.

       6 - Boot Version:  The WTP's boot loader's version number.

    Length:  Length of vendor specific encoding of WTP information.

    Value:  Vendor specific encoding of WTP information.

== draft-ietf-capwap-protocol-specification-02.txt, Section 11.1.1,  
"Split MAC" ==

11.1.1.  Split MAC

    This section shows the division of labor between the WTP and the AC
    in a Split MAC architecture.  Figure 4 shows the clear separation of
    functionality among CAPWAP components.

         Function                               Location
             Distribution Service                      AC
             Integration Service                       AC
             Beacon Generation                         WTP
             Probe Response Generation                 WTP
             Power Mgmt/Packet Buffering               WTP
             Fragmentation/Defragmentation             WTP/AC
             Assoc/Disassoc/Reassoc                    AC

        802.11e
             Classifying                               AC
             Scheduling                                WTP/AC
             Queuing                                   WTP

        802.11i
             802.1X/EAP                                AC
             RSNA Key Management                       AC
             802.11 Encryption/Decryption              WTP/AC

    Figure 4: Mapping of 802.11 Functions for Split MAC Architecture

    The Distribution and Integration services reside on the AC, and
    therefore all user data is tunneled between the WTP and the AC.  As
    noted above, all real-time IEEE 802.11 services, including the  
beacon
    and probe response frames, are handled on the WTP.

    All remaining IEEE 802.11 MAC management frames are supported on the

Calhoun, Editor, et al.  Expires December 23, 2006             [Page 97]
Internet-Draft        CAPWAP Protocol Specification            June 2006

    AC, including the Association Request which allows the AC to be
    involved in the access policy enforcement portion of the IEEE 802.11
    protocol.  The IEEE 802.1X and IEEE 802.11i key management function
    are also located on the AC.  This implies that the AAA client also
    resides on the AC.

    While the admission control component of IEEE 802.11e resides on the
    AC, the real time scheduling and queuing functions are on the WTP.
    Note this does not exclude the AC from providing additional policing
    and scheduling functionality.

    Note that in the following figure, the use of '( - )' indicates that
    processing of the frames is done on the WTP.

              Client                       WTP                        AC

                       Beacon
              <-----------------------------
                    Probe Request
              ---------------------------- 
( - )------------------------->
                    Probe Response
              <-----------------------------
                               802.11 AUTH/Association
               
<--------------------------------------------------------->
                   Mobile Config Request[Add Mobile (Clear Text,  
802.1X)]
                                               
<------------------------->
                     802.1X Authentication & 802.11i Key Exchange
               
<--------------------------------------------------------->
                   Mobile Config Request[Add Mobile (AES-CCMP, PTK=x)]
                                               
<------------------------->
                                802.11 Action Frames
               
<--------------------------------------------------------->
                                    802.11 DATA (1)
              <--------------------------- 
( - )------------------------->

    Figure 5: Split MAC Message Flow

    Figure 5 provides an illustration of the division of labor in a  
Split
    MAC architecture.  In this example, a WLAN has been created that is
    configured for IEEE 802.11i, using AES-CCMP for privacy.  The
    following process occurs:

    o  The WTP generates the IEEE 802.11 beacon frames, using  
information
       provided to it through the Add WLAN (see Section Section 11.9.1)
       message element.

    o  The WTP processes the probe request and responds with a
       corresponding probe response.  The probe request is then  
forwarded
       to the AC for optional processing.

    o  The WTP forwards the IEEEE 802.11 Authentication and Association
       frames to the AC, which is responsible for responding to the
       client.

    o  Once the association is complete, the AC transmits an CAPWAP Add
       Mobile Station request to the WTP (see Section Section 4.4.8.  In
       the above example, the WLAN is configured for IEEE 802.1X, and
       therefore the '802.1X only' policy bit is enabled.

    o  If the WTP is providing encryption/decryption services, once the
       client has completed the IEEE 802.11i key exchange, the AC
       transmits another Add Mobile request to the WTP, stating the
       security policy to enforce for the client (in this case AES- 
CCMP),
       as well as the encryption key to use.  If encryption/ 
decryption is
       handled in the AC, the IEEE 802.11 Add Mobile Station request
       would not include the RSN Information Element.

    o  The WTP forwards any 802.11 Action frames received to the AC.

    o  All client data frames are tunneled between the WTP and the AC.
       Note that the WTP is responsible for encrypting and decrypting
       frames, if it was indicated in the Add Mobile request.

== draft-ietf-capwap-protocol-specification-02.txt,Section 11.1.2,  
"Local MAC" ==

11.1.2.  Local MAC

    This section shows the division of labor between the WTP and the AC
    in a Local MAC architecture.  Figure 6 shows the clear separation of
    functionality among CAPWAP components.

Calhoun, Editor, et al.  Expires December 23, 2006             [Page 99]
Internet-Draft        CAPWAP Protocol Specification            June 2006

         Function                               Location
             Distribution Service                      WTP
             Integration Service                       WTP
             Beacon Generation                         WTP
             Probe Response Generation                 WTP
             Power Mgmt/Packet Buffering               WTP
             Fragmentation/Defragmentation             WTP
             Assoc/Disassoc/Reassoc                    WTP

        802.11e
             Classifying                               WTP
             Scheduling                                WTP
             Queuing                                   WTP

        802.11i
             802.1X/EAP                                AC
             RSNA Key Management                       AC
             802.11 Encryption/Decryption              WTP

    Figure 6: Mapping of 802.11 Functions for Local AP Architecture

    Given the Distribution and Integration Services exist on the WTP,
    client data frames are not forwarded to the AC, with the exception
    listed in the following paragraphs.

    While the MAC is terminated on the WTP, it is necessary for the  
AC to
    be aware of mobility events within the WTPs.  As a consequence, the
    WTP MUST forward the IEEE 802.11 Association Requests to the AC.   
The
    AC MAY reply with a failed Association Response if it deems it
    necessary, and upon receipt of a failed Association Response from  
the
    AC, the WTP must send a Disassociation frame to the mobile station.

    The IEEE 802.1X and RSNA Key Management function resides in the AC.
    Therefore, the WTP MUST forward all IEEE 802.1X/RSNA Key Management
    frames to the AC and forward the associated responses to the  
station.
    This implies that the AAA client also resides on the AC.

    Note that in the following figure, the use of '( - )' indicates that
    processing of the frames is done on the WTP.

Calhoun, Editor, et al.  Expires December 23, 2006            [Page 100]
Internet-Draft        CAPWAP Protocol Specification            June 2006

              Client                       WTP                        AC

                       Beacon
              <-----------------------------
                        Probe
              <---------------------------->
                     802.11 AUTH
              <-----------------------------
                                  802.11 Association
              <--------------------------- 
( - )------------------------->
                   Mobile Config Request[Add Mobile (Clear Text,  
802.1X)]
                                               
<------------------------->
                     802.1X Authentication & 802.11i Key Exchange
               
<--------------------------------------------------------->
                                802.11 Action Frames
               
<--------------------------------------------------------->
                     Mobile Config Request[Add Mobile (AES-CCMP, PTK=x)]
                                               
<------------------------->
                      802.11 DATA
              <----------------------------->

    Figure 7: Local MAC Message Flow

    Figure 7 provides an illustration of the division of labor in a  
Local
    MAC architecture.  In this example, a WLAN has been created that is
    configured for IEEE 802.11i, using AES-CCMP for privacy.  The
    following process occurs:

    o  The WTP generates the IEEE 802.11 beacon frames, using  
information
       provided to it through the Add WLAN (see Section 11.9.1) message
       element.

    o  The WTP processes the probe request and responds with a
       corresponding probe response.

    o  The WTP forwards the IEEE 802.11 Authentication and Association
       frames to the AC.

    o  Once the association is complete, the AC transmits an CAPWAP Add
       Mobile Station message element to the WTP (see Section
       Section 4.4.8.  In the above example, the WLAN is configured for
       IEEE 802.1X, and therefore the '802.1X only' policy bit is
       enabled.

    o  The WTP forwards all IEEE 802.1X and IEEE 802.11i key exchange
       messages to the AC for processing.

    o  The AC transmits another Add Mobile Station message element to  
the
       WTP, stating the security policy to enforce for the client (in
       this case AES-CCMP), as well as the encryption key to use.  The
       Add Mobile Station message element MAY include a VLAN name, which
       when present is used by the WTP to identify the VLAN on which the
       user's data frames are to be bridged.

    o  The WTP forwards any IEEE 802.11 Action frames received to the  
AC.

    o  The WTP may locally bridge client data frames (and provide the
       necessary encryption and decryption services).  The WTP may also
       tunnel client data frames to the AC, using 802.3 frame tunnel  
mode
       or 802.11 frame tunnel mode.

== Saravanan's Proposal ==

All,

I wanted to give a more detailed explanation for the IEEE 802.11i  
Considerations requirement. This note describes how CAPWAP can be  
updated to satisfy this requirement

I would like to use this to highlight the proposal being put forward.

 From RFC 4564, Section 5.1.10 IEEE 802.11i Considerations

    Protocol Requirement:

    The CAPWAP protocol MUST determine the exact structure of the
    centralized WLAN architecture in which authentication needs to be
    supported, i.e., the location of major authentication components.
    This may be achieved during WTP initialization where major
    capabilities are distinguished.

    The protocol MUST allow for the exchange of key information when
    authenticator and encryption roles are located in distinct entities.

Following the requirement, CAPWAP needs;

1. to incorporate authentication & encryption locations in
    capabilities exchange

2. to exchange key information when authentication and crypt are
    located in different network entities

Basic case:

AC does both IEEE 802.11i authentication and cryptography. For 4-way
exchange, AC tracks the KeyRSC, which it then uses for Message-3,
i.e., AC calculates KeyMIC and updates EAPoL frame.

                                                   - 802.11i  
Authentication
                                                   - 802.11i Crypto
                                                      (KeyRSC  
maintained here)

    +----------+                 +-----+                     +------+
    | Terminal |                 | WTP |                     |  AC  |
    +----------+                 +-----+                     +------+
         |                          |                            |
         |                    802.1x Authentication              |
         |<=====================================================>|
         |                          |                            |
        PMK                         |                           PMK
         |                          |                            |
       Generate                     |                        Generate
        SNonce                      |                         ANonce
         |                          |                            |
         |                          |                            |
         |                      Message-1                        |
         |<-------------------------|<---------------------------|
         |       EAPoL Packet       |        CAPWAP Packet       |
       Receive                      |                            |
        ANonce                      |                            |
       Generate                     |                            |
        PTK                         |                            |
         |                          |                            |
         |                      Message-2                        |
         |------------------------->|--------------------------->|
         |       EAPoL Packet       |        CAPWAP Packet       |
         |                          |                        Receive
         |                          |                        SNonce
         |                          |                            |
         |                          |                       Generate
         |                          |                          PTK
         |                          |                          GTK
         |                      Message-3                        |
         |<-------------------------|<---------------------------|
         |       EAPoL Packet       |   CAPWAP Packet            |
         |                          |      |                     |
         |                          |      | +-----------------------+
         |                          |       \|- EAPoL Frame          |
       Receive                      |        +-----------------------+
        GTK                         |                            |
         |                          |                            |
         |                          |                            |
         |                      Message-4                        |
         |------------------------->|--------------------------->|
         |       EAPoL Packet       |         CAPWAP Packet      |
         |                          |                            |

Case specified by RFC 4564:

The 802.11i Considerations requirement considers the case where 802.11i
authentication is at AC and 802.11i crypto is at WTP. So now, the WTP
maintains the KeyRSC while the AC requires this information to generate
the EAPoL frame for Message-3 of the 4-way handshake.

The diagram below shows this;

                             - 802.11i Crypto
                          (KeyRSC maintained here)      - 802.11i  
Authentication

    +----------+                 +-----+                     +------+
    | Terminal |                 | WTP |                     |  AC  |
    +----------+                 +-----+                     +------+
         |                          |                            |
         |                    802.1x Authentication              |
         |<=====================================================>|
         |                          |                            |
        PMK                         |                           PMK
         |                          |                            |
       Generate                     |                        Generate
        SNonce                      |                         ANonce
         |                          |                            |

In this case, the EAPoL frame generated by the AC will not be based on
the prevailing value of the KeyRSC, as this counter is maintained by
the WTP.

This problem is currently not solved in the CAPWAP specifications.

Proposal:

The proposal is to include a CAPWAP Key Configuration message that can
transport the EAPoL frame between AC and WTP before being sent to the
client (terminal).

Key Configuration is a control message sent by the AC to the WTP. The
message contains Message-3 of the 4-way handshake - including the
EAPoL-frame. However, the EAPoL frame has its KeyMIC field unassigned as
the AC cannot accurately calculate this.

So on receiving the Key Configuration - containing EAPoL frame with
unassigned KeyMIC field, the WTP retrieves the value of the KeyRSC it
maintains and computes the corresponding KeyMIC.

The EAPoL frame is then updated and Message-3 of the 4-way handshake is
reconstructed before being sent over the wireless link to the client.

The diagram below illustrates this;

                             - 802.11i Crypto
                          (KeyRSC maintained here)      - 802.11i  
Authentication

    +----------+                 +-----+                     +------+
    | Terminal |                 | WTP |                     |  AC  |
    +----------+                 +-----+                     +------+
         |                          |                            |
         |                    802.1x Authentication              |
         |<=====================================================>|
         |                          |                            |
        PMK                         |                           PMK
         |                          |                            |
       Generate                     |                        Generate
        SNonce                      |                         ANonce
         |                          |                            |
         |                          |                            |
         |                      Message 1                        |
         |<-------------------------|<---------------------------|
         |       EAPoL Packet       |        CAPWAP Packet       |
       Receive                      |                            |
        ANonce                      |                            |
       Generate                     |                            |
        PTK                         |                            |
         |                          |                            |
         |                      Message 2                        |
         |------------------------->|--------------------------->|
         |       EAPoL Packet       |        CAPWAP Packet       |
         |                          |                        Receive
         |                          |                        SNonce
         |                          |                            |
         |                          |                       Generate
         |                          |                          PTK
         |                          |                          GTK
         |                          |          Message 3         |
         |                          |<===========================|
         |                          |        CAPWAP Packet       |
         |                          |      (Key Configuration)   |
         |                          |      | +-----------------------+
         |                          |       \|- GTK-Flag             |
         |                 -Retrieve KeyRSC  |- Encryption-Data(PTK) |
         |                 -Update KeyMIC    |- Encryption-Data(GTK) |
         |                 -Reconstruct      |- EAP-Frame            |
         |                     Message-3     +-----------------------+
         |                          |                            |
         |<-------------------------|                            |
         |       EAPoL Packet       |                            |
      Receive                       |                            |
       GTK                          |                            |
         |                      Message 4                        |
         |------------------------->|--------------------------->|
         |       EAPoL Packet       |        CAPWAP Packet       |
         |                          |                            |

This proposal very simply solves the problem while directly addressing
the requirement for IEEE 802.11i Considerations.

Cheers,

Saravanan

---

From: "T. Charles Clancy" <[email-masked]>
Date: Sat, 23 Sep 2006 13:15:30 -0400 (EDT)

I think all the discussions about the requirements and taxonomy, etc, 
overcomplicate the matter.  It's a simple technical point in the protocol.

First of all, this applies to the scenario where split-mac is being used, 
and the WTP is performing the packet encryption/decryption.

Saravanan's point:  In order to perform the 4-way handshake, the AC needs 
to know the KeyRSC.  In the aforementioned scenario, the KeyRSC resides at 
the WTP.  This has nothing to do with optional features; as-is the 
protocol just plain won't work.

It seems to me that the WG has a couple options:

1. Decide that Saravanan's point is technically incorrect, and not inline
    with 802.11i.
2. Decide that we don't want to support split-mac with the WTP doing the
    packet crypto.
3. Fix the protocol by having some message to sync the KeyRSC values.

Without rereading 802.11i, I think Saravanan has a point, and we should 
fix the protocol.  Of course, Cisco has working code that somehow operates 
in this scenario.  Perhaps Pat and Bob could fill us in on how the KeyRSC 
is handled in existing systems?  Perhaps different KeyRSC values are used, 
and the client supplicants just don't notice?

Unfortunately for the next few weeks my Internet connection is through an 
extremely slow WiFi network (motivation to finish CAPWAP) that would 
probably implode upon itself if I tried to download the 11i spec (oh the 
irony).  Without that as a reference, I can't speak with very much 
authority.

--
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap