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

From: "Saravanan Govindan" <[email-masked]>
Date: Wed, 7 Jun 2006 13:23:42 +0800

Hi Mike,

My concern is with where the KeyRSC value is maintained for the purposes
of both the 4-way handshake and group key handshake. Section 11.3
describes group key refresh operations alone. 

The issue is that the KeyRSC can be maintained in either the WTP or AC.
And the prevailing KeyRSC value is needed for the 4-way handshake
(particularly for message 3) and group key handshake (particularly for
message 1). 

I think the suggestion for transmitting KeyRSC value from WTP to AC may
cause mismatches due to propagation between WTP and AC. This is the
reason for suggesting a new CAPWAP control message that carries
message-3 (in case of 4-way handshake) with unassigned KeyRSC from AC to
WTP. The WTP can then use the current value of KeyRSC for message-3. 

I will re-send a formatted note with this suggestion.

Cheers,

Saravanan

________________________________

From: Michael Montemurro [mailto:[email-masked]] 
Sent: Sunday, June 04, 2006 3:03 AM
To: Saravanan Govindan
Cc: Pat Calhoun (pacalhou); capwap
Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i
Considerations

Saravanan,

Take a look at section 11.3. Would it be sufficient for the WTP to
transmit the KeyRSC value as a TLV in the 802.11 config response?

Cheers,

 Mike

On 6/3/06, Michael Montemurro <[email-masked]> wrote: 

Saravanan, 

I took a look again at the latest draft for IEEE 802.11i, and as I
understand it, the GTK 1 message needs the sequence number of the

last transmitted broadcast frame.

In the split MAC case, the AC should know the sequence number because it
would set it. In the local MAC case, the AC would have to

query the WTP for the sequence number. 

So, I believe what you require is a mechanism for the AC to query the
WTP for the sequence number in the local MAC case. Is that correct?

The keyMIC should not be an issue because in either the local MAC or the
split MAC case, the AC would have all the information it needs. 

The only requirement would be for the AC to hold onto the KEK for the
STA to calculate the MIC for the EAPoL frame.

Would that be correct?

Cheers,

Mike

On 5/26/06, Saravanan Govindan < [email-masked]
<mailto:[email-masked]> > wrote: 

	Hi,

	This is a copy-and-paste from previous email.

	 
	In cases where IEEE 802.11i encryption/decryption is located in
a WTP and IEEE 
	 
	802.11i authenticator is located in an AC, there is a mismatch
in tracking 

	 
	KeyRSC values (draft-ietf-capwap-objectives-04.txt) Section
5.1.10. The CAPWAP 
	protocol must allow the 4-way and Group-key exchanges to use
accurate values 
	of KeyRSC and KeyMIC in all cases. 

	My recommendation:

	Introduce new Key Configuration & Key Configuration Response
messages as part 
	of Message Types. Key Configuration message will be used to
exchange 3rd message (for 4-way exchange & with unassigned KeyMIC and
KeyRSC fields) and 1st message (for group-key exchange & with unassigned
KeyMIC and KeyRSC fields). 

	 
	 
	I was looking for these 2 messages in the new draft. However, I
am open to other ways of accomplishing the objective. 
	 
	Cheers,

	

	 
	Saravanan

	
________________________________

	From: Michael Montemurro [mailto: [email-masked]] 
	Sent: Friday, May 26, 2006 8:30 AM 
	To: Pat Calhoun (pacalhou)
	Cc: Saravanan Govindan; capwap
	Subject: Re: [Capwap] Clarification of Issue 43: IEEE 802.11i
Considerations

	The only text that I could identify that was missing here was
information on how the GTK was handled.

	If there is more information or clarification, please let me
know.

	Cheers,

	Mike

	On 5/23/06, Pat Calhoun (pacalhou) < [email-masked]
<mailto:[email-masked]> > wrote: 

	I have re-opened issue 43, but it would be useful if you could
provide a
	high level example (outline) of what you would like to see. 
	
	Pat Calhoun 
	CTO, Wireless Networking Business Unit
	Cisco Systems

	> -----Original Message-----
	> From: Saravanan Govindan [mailto:
[email-masked]
<mailto:[email-masked]> ]
	> Sent: Tuesday, May 23, 2006 12:24 AM
	> To: capwap
	> Subject: [Capwap] Clarification of Issue 43: IEEE 802.11i
	> Considerations
	>
	> All,
	> 
	> I believe this issue 43 - also a Mandatory Objective - is 
	> still open. My suggestion is to update the 802.11 binding
	> section to reflect steps local-MAC and split-MAC cases.
	>
	> Saravanan 
	>
	>
_________________________________________________________________ 
	> 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 

_________________________________________________________________
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: Fri, 16 Jun 2006 21:47:22 -0400

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     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     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
>

---

From: "Saravanan Govindan" <[email-masked]>
Date: Mon, 19 Jun 2006 12:18:06 +0800

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. 

                                          Value

 

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. 

 

      0                   1                   2                   3

     |    GTK-Flag   |                   Reserved                    |

     |                        Encryption-Data                        |

     |                          EAPoL-Frame                          |

 

     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 <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.   

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

      0                   1                   2                   3

     |    GTK-Flag   |                   Reserved                    |

     |                        Encryption-Data                        |

     |                          EAPoL-Frame                          |

 

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

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

 

[END OF SUGGESTED TEXT]

Saravanan

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Mon, 19 Jun 2006 10:15:04 -0700

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, 

Cheers,

Saravanan

 

Saravanan,

Cheers,

Mike

Hi Mike, 

                                          Value

 

 

 

      0                   1                   2                   3

     |    GTK-Flag   |                   Reserved                    |

     |                        Encryption-Data                        |

     |                          EAPoL-Frame                          |

 

 

      0                   1                   2                   3

     |    GTK-Flag   |                   Reserved                    |

     |                        Encryption-Data                        |

     |                          EAPoL-Frame                          |

 

 

[END OF SUGGESTED TEXT]

Saravanan

---

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

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

 -Bob

Hi Mike, 

Cheers,

Saravanan

 

Saravanan,

Cheers,

Mike

Hi Mike, 

                                          Value

 

 

 

      0                   1                   2                   3

     |    GTK-Flag   |                   Reserved                    |

     |                        Encryption-Data                        |

     |                          EAPoL-Frame                          |

 

 

      0                   1                   2                   3

     |    GTK-Flag   |                   Reserved                    |

     |                        Encryption-Data                        |

     |                          EAPoL-Frame                          |

 

 

[END OF SUGGESTED TEXT]

Saravanan

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Mon, 19 Jun 2006 20:14:13 -0700

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

Saravanan

 -Bob

Hi Mike, 

Cheers,

Saravanan

 

Saravanan,

Cheers,

Mike

Hi Mike, 

                                          Value

 

 

 

      0                   1                   2                   3

     |    GTK-Flag   |                   Reserved                    |

     |                        Encryption-Data                        |

     |                          EAPoL-Frame                          |

 

 

      0                   1                   2                   3

     |    GTK-Flag   |                   Reserved                    |

     |                        Encryption-Data                        |

     |                          EAPoL-Frame                          |

 

 

[END OF SUGGESTED TEXT]

Saravanan