Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations

From: "Saravanan Govindan" <[email-masked]>
Date: Tue, 20 Jun 2006 11:52:09 +0800

If this is the case, perhaps more clarification can be provided. In
particular, which part of the document deals with this? 

Saravanan

 

________________________________

From: Bob O'Hara (boohara) [mailto:[email-masked]] 
Sent: Tuesday, June 20, 2006 11:14 AM
To: capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i
Considerations

This can be done with the current messages.  It is already being done in
shipping products using the LWAPP protocol, from which these messages
were derived.

 -Bob

________________________________

From: Saravanan Govindan [mailto:[email-masked]] 
Sent: Monday, June 19, 2006 6:37 PM
To: Bob O'Hara (boohara); capwap
Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i
Considerations

Consider the 4-way handshake in architecture designs where the WTP
maintains the Key-RSC and the AC constructs EAPOL messages (this is one
of the major designs brought out in the Architecture Taxonomy). Now, to
construct Message 3 of the 4-way handshake, the AC computes the Key-MIC
based on the prevailing Key-RSC. Since the Key-RSC is maintained by the
WTP, there needs to be some way to transfer this information to the AC. 

I am open to a different way of doing this from what I've suggested
earlier - using of separate Key Configuration message. My concern is
only to see that this can be accomplished in the CAPWAP protocol.

Saravanan

________________________________

From: Bob O'Hara (boohara) [mailto:[email-masked]] 
Sent: Tuesday, June 20, 2006 1:15 AM
To: capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i
Considerations

I believe that Mike is correct.  There is no need to transfer the
sequence counter from the WTP to the AC, if the AC is where the EAPOL
messages are constructed and the WTP is where the sequence counters are
maintained.  A careful read of 802.11i on the use of that field will
make this clear.

 -Bob

________________________________

From: Saravanan Govindan [mailto:[email-masked]] 
Sent: Sunday, June 18, 2006 9:18 PM
To: Michael Montemurro
Cc: capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i
Considerations

Hi Mike, 

There are a number of designs for IEEE 802.11i. And I believe the
description you noted below is one of them. In other designs, the
sequence counter is maintained at the point where encryption is
performed. 

>From my understanding of the update you mention to Add WLAN, the
assumption seems to be the AC manages the transmit sequence counter. So
by using the updated Add WLAN, the AC informs the WTP about the
prevailing sequence counter value. Have I understood this right?

If what I've got above is right, we are still left with the case where
the sequence counter is maintained at the WTP. The Objectives highlights
this as a mandatory requirement for the protocol. 

I'd appreciate if you could post the text relating to the update you
mention for Add WLAN. This can help better understand how the update
address both the designs. 

Cheers,

Saravanan

 

________________________________

From: Michael Montemurro [mailto:[email-masked]] 
Sent: Saturday, June 17, 2006 9:47 AM
To: Saravanan Govindan
Cc: capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i
Considerations

Saravanan,

I have looked through IEEE 802.11i as well as talked with others who had
implemented IEEE 802.11i. The treatment of the KeyRSC setting is not
explained as well as it could be in the IEEE 802.11i draft. In many
implementations, the Authenticator sets the transmit sequence counter
with the new GTK and passes them both down to the MAC. The Authenticator
then transmits this information to the STA as part of the GTK1 EAPoL
message. Both the STA and the WTP will then begin using the new TSC and
the group key to encrypt broadcast/multicast traffic. 

To address this in CAPWAP I have updated the AddWLAN message to include
the transmit sequence counter for the GTK. That should address any
issues with counters and key states.

Cheers,

Mike

On 6/7/06, Saravanan Govindan <[email-masked]>
wrote: 

Hi Mike, 

Following from my earlier note, this is the suggestion for handling
KeyRSC maintained in a WTP. 

The suggestion is to include a new IEEE 802.11 specific CAPWAP control
messages called "IEEE 802.11 Key Configuration". 

Following from CAPWAP Specifications-01;

CAPWAP Control Message                    Message Type

                                          Value

IEEE 802.11 Key Configuration             3398914

IEEE 802.11 Key Configuration Response    3398915

The suggested text follows;

[START OF SUGGESTED TEXT]

11.7.3. IEEE 802.11 Key Configuration

The IEEE 802.11 Key Configuration CAPWAP message is used in WTP designs
in which IEEE 802.11i authenticator functions are performed by the AC
and IEEE 802.11i cryptographic functions (encryption/decryption) are
performed by the WTPs. 

This CAPWAP message is sent from the AC to the WTP. It must contain
either of the following 2 message elements. 

 

11.7.3.1 <http://11.7.3.1/>      IEEE 802.11 4-way Handshake 

The IEEE 802.11 4-way Handshake message element is sent by the AC to the
WTP during the 4-way handshake. It contains Message-3 of the 4-way
handshake with unassigned values as the AC is unaware of the prevailing
KeyRSC sequence counter maintained by the WTP.   

Message-1, Message-2 and Message-4 of the 4-way handshake are
transported within CAPWAP data packets between AC and WTP. 

The IEEE 802.11 4-way Handshake message element contains the following
values:

      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

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |    GTK-Flag   |                   Reserved                    |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                        Encryption-Data                        |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                          EAPoL-Frame                          |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation

     0 - New GTK, KeyMIC is calculated with KeyRSC = 0

     1 - Existing GTK, KeyMIC is calculated with prevailing KeyRSC value

Encryption-Data: Contains PTK and/or GTK

EAPoL-Frame: Contains Message-3 of 4-way handshake with unassigned
fields

Upon receipt of the Key Configuration message from the AC, the WTP
performs the following operations:

    i.            Assigns the corresponding value to the KeyRSC field of
the EAPoL-Frame 

ii.            Calculates KeyMIC with Encrytion-Data and KeyRSC

iii.            Updates Message-3 of 4-way handshake

iv.            Continues regular 4-way handshake with wireless terminals

 

11.7.3.2 <http://11.7.3.2/>      IEEE 802.11 Group Key Handshake 

The IEEE 802.11 Group Key Handshake message element is sent by the AC to
the WTP during the group key handshake. It contains Message-1 of the
group key handshake with unassigned values as the AC is unaware of the
prevailing KeyRSC sequence counter maintained by the WTP.   

Message-2 of the group key handshake is transported within a CAPWAP data
packet between AC and WTP. 

The IEEE 802.11 Group Key Handshake message element contains the
following values:

      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

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |    GTK-Flag   |                   Reserved                    |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                        Encryption-Data                        |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |                          EAPoL-Frame                          |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

GTK-Flag: An 8-bit flag that determines the type of KeyMIC calculation

     0 - New GTK, KeyMIC is calculated with KeyRSC = 0

     1 - Existing GTK, KeyMIC is calculated with prevailing KeyRSC value

Encryption-Data: Contains PTK and/or GTK

EAPoL-Frame: Contains Message-1 of group key handshake with unassigned
fields

Upon receipt of the Key Configuration message from AC, the WTP performs
the following operations:

    i.            Assigns the corresponding value to the KeyRSC field of
the EAPoL-Frame 

ii.            Calculates KeyMIC with Encrytion-Data and KeyRSC

iii.            Updates Message-1 of group key handshake

iv.            Continues regular group handshake with wireless terminals

 

11.7.4     IEEE 802.11 Key Configuration Response

The IEEE 802.11 Key Configuration Response CAPWAP message is sent by the
WTP to the AC as an acknowledgement of the receipt of an IEEE 802.11 Key
Configuration Request. 

[END OF SUGGESTED TEXT]

Saravanan

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

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

---

From: "Michael Montemurro" <[email-masked]>
Date: Tue, 20 Jun 2006 10:00:51 -0400

Saravanan,

I've updated section 11.3 to deal with the GTK exchange and the handling of
the KeyRSC in draft -02 to address your comments. I also provided a
mechanism for the AC to transmit the keyRSC to the WTP using the updateWLAN
message element as part of the Group Key exchange.

We're finalizing the -02 draft this week and you should be able to look at
it when we post it later this week.

Cheers,

Mike

On 6/19/06, Saravanan Govindan <[email-masked]> wrote:
>  ------------------------------
>
> *From:* Bob O'Hara (boohara) [mailto:[email-masked]]
> *Sent:* Tuesday, June 20, 2006 11:14 AM
>
> *To:* capwap
> *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderations
>
>
>
> shipping products using the LWAPP protocol, from which these messages were
> derived.
>
>  -Bob
>
>
>
>
>
>  ------------------------------
>
> *From:* Saravanan Govindan [mailto:[email-masked]]
> *Sent:* Monday, June 19, 2006 6:37 PM
> *To:* Bob O'Hara (boohara); capwap
> *Subject:* RE: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderations
>
> maintains the Key-RSC and the AC constructs EAPOL messages (this is one of
> the major designs brought out in the Architecture Taxonomy). Now, to
> based on the prevailing Key-RSC. Since the Key-RSC is maintained by the WTP,
> there needs to be some way to transfer this information to the AC.
>
>
>
> earlier – using of separate Key Configuration message. My concern is only to
> see that this can be accomplished in the CAPWAP protocol.
>
>
>
> Saravanan
>
>
>
>
>
>
>  ------------------------------
>
> *From:* Bob O'Hara (boohara) [mailto:[email-masked]]
> *Sent:* Tuesday, June 20, 2006 1:15 AM
> *To:* capwap
> *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderations
>
>
>
> I believe that Mike is correct.  There is no need to transfer the sequence
> counter from the WTP to the AC, if the AC is where the EAPOL messages are
> constructed and the WTP is where the sequence counters are maintained.  A
> careful read of 802.11i on the use of that field will make this clear.
>
>  -Bob
>
>
>
>
>
>  ------------------------------
>
> *From:* Saravanan Govindan [mailto:[email-masked]]
> *Sent:* Sunday, June 18, 2006 9:18 PM
> *To:* Michael Montemurro
> *Cc:* capwap
> *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderations
>
> Hi Mike,
>
>
>
> description you noted below is one of them. In other designs, the sequence
> counter is maintained at the point where encryption is performed.
>
>
>
> assumption seems to be the AC manages the transmit sequence counter. So by
> using the updated Add WLAN, the AC informs the WTP about the prevailing
> sequence counter value. Have I understood this right?
>
> If what I've got above is right, we are still left with the case where the
> sequence counter is maintained at the WTP. The Objectives highlights this as
> a mandatory requirement for the protocol.
>
>
>
> mention for Add WLAN. This can help better understand how the update address
> both the designs.
>
>
>
> Cheers,
>
>
>
> Saravanan
>
>
>
>
>
>
>
>
>
>
>  ------------------------------
>
> *From:* Michael Montemurro [mailto:[email-masked]]
> *Sent:* Saturday, June 17, 2006 9:47 AM
> *To:* Saravanan Govindan
> *Cc:* capwap
> *Subject:* Re: [Capwap] Clarification of Issue 43: IEEE 802.11iConsiderations
>
>
>
> Saravanan,
>
>
>
> implementations, the Authenticator sets the transmit sequence counter with
> the new GTK and passes them both down to the MAC. The Authenticator then
> transmits this information to the STA as part of the GTK1 EAPoL message.
> Both the STA and the WTP will then begin using the new TSC and the group key
> to encrypt broadcast/multicast traffic.
>
>
>
> the transmit sequence counter for the GTK. That should address any issues
> with counters and key states.
>
>
>
> Cheers,
>
>
>
> Mike
>
>
>
>
>
> On 6/7/06, *Saravanan Govindan* <[email-masked]>
> wrote:
>
> Hi Mike,
>
>
>
> Following from my earlier note, this is the suggestion for handling KeyRSC
> maintained in a WTP.
>
>
>
> The IEEE 802.11 Key Configuration CAPWAP message is used in WTP designs in
> which IEEE 802.11i authenticator functions are performed by the AC and
> IEEE 802.11i cryptographic functions (encryption/decryption) are performed
> by the WTPs.
>
>
>
> This CAPWAP message is sent from the AC to the WTP. It must contain either
> of the following 2 message elements.
>
>
>
>
>
>
>
>
>
> 11.7.3.1     IEEE 802.11 4-way Handshake
>
>
>
> WTP during the 4-way handshake. It contains Message-3 of the 4-way handshake
> with unassigned values as the AC is unaware of the prevailing KeyRSC
> sequence counter maintained by the WTP.
>
>
>
> Message-1, Message-2 and Message-4 of the 4-way handshake are transported
> within CAPWAP data packets between AC and WTP.
>
>
>
>      0 – New GTK, KeyMIC is calculated with KeyRSC = 0
>
>
>
>      1 – Existing GTK, KeyMIC is calculated with prevailing KeyRSC value
>
>
>
> EAPoL-Frame: Contains Message-3 of 4-way handshake with unassigned fields
>
>
>
> 11.7.3.2     IEEE 802.11 Group Key Handshake
>
>
>
> the WTP during the group key handshake. It contains Message-1 of the group
> key handshake with unassigned values as the AC is unaware of the prevailing
> The IEEE 802.11 Group Key Handshake message element contains the following
> values:
>
>
>
>       0                   1                   2                   3
>
>      0 – New GTK, KeyMIC is calculated with KeyRSC = 0
>
>
>
>      1 – Existing GTK, KeyMIC is calculated with prevailing KeyRSC value
>
>
>