From lwapp@frascone.com Sun Jun 8 20:40:41 2003 From: lwapp@frascone.com (David Frascone) Date: Sun, 8 Jun 2003 14:40:41 -0500 Subject: [Lwapp] Test, please ignore Message-ID: <20030608194041.GA5133@wolverine> test -- David Frascone Fingers v1.0 -- The original mail processor. From lwapp@frascone.com Sun Jun 8 20:42:06 2003 From: lwapp@frascone.com (David Frascone) Date: Sun, 8 Jun 2003 14:42:06 -0500 Subject: [Lwapp] Re: Can't see LWAPP archives In-Reply-To: <001101c32cec$557d39c0$3a083a18@yourw92p4bhlzg> References: <001101c32cec$557d39c0$3a083a18@yourw92p4bhlzg> Message-ID: <20030608194206.GB5133@wolverine> That's because no messages had been sent to the list. It is there now, after I sent a test message. On Saturday, 07 Jun 2003, Maureen Stillman wrote: > I'm unable to get to the LWAPP archives. Here is the URL: > http://mail.frascone.com/pipermail/public/lwapp/ > > here is the message: The requested URL /pipermail/public/lwapp/ was not > found on this server > > Thanks. > > -- maureen > > -- David Frascone How do you pronounce my name? With reverence. From lwapp@frascone.com Sun Jun 8 20:46:19 2003 From: lwapp@frascone.com (Pat R. Calhoun) Date: Sun, 8 Jun 2003 12:46:19 -0700 Subject: [Lwapp] Test, please ignore Message-ID: <40301581B2962B448690A023EF16DFE157A23E@bsn-mail-01.bstormnetworks.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C32DF6.A1908FCD Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 d2UgcmVhbGx5IG5lZWQgdG8gY2hhdA0KIA0KUGF0Qw0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0gDQoJRnJvbTogRGF2aWQgRnJhc2NvbmUgW21haWx0bzpkYXZlQGZyYXNjb25lLmNvbV0g DQoJU2VudDogU3VuIDYvOC8yMDAzIDEyOjQwIFBNIA0KCVRvOiBsd2FwcEBmcmFzY29uZS5jb20g DQoJQ2M6IA0KCVN1YmplY3Q6IFtMd2FwcF0gVGVzdCwgcGxlYXNlIGlnbm9yZQ0KCQ0KCQ0KDQoJ dGVzdA0KCQ0KCS0tDQoJRGF2aWQgRnJhc2NvbmUNCgkNCgkgICAgICAgICAgRmluZ2VycyB2MS4w IC0tIFRoZSBvcmlnaW5hbCBtYWlsIHByb2Nlc3Nvci4NCglfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KCUx3YXBwIG1haWxpbmcgbGlzdA0KCUx3YXBwQGZy YXNjb25lLmNvbQ0KCWh0dHA6Ly9tYWlsLmZyYXNjb25lLmNvbS9tYWlsbWFuL2xpc3RpbmZvL2x3 YXBwDQoJDQoNCg== ------_=_NextPart_001_01C32DF6.A1908FCD Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhQTAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBYAD AA4AAADTBwYACAAMAC4AEwAAADUBASCAAwAOAAAA0wcGAAgADAAuABMAAAA1AQEJgAEAIQAAADhG ODdGRjY2REE0MUVFNEU5RkMyMTlERTNCRDcyRkYxAJgHAQOQBgDYDQAAOAAAAB8AGgABAAAAEgAA AEkAUABNAC4ATgBvAHQAZQAAAAAAAwA2AAAAAAAfADcAAQAAAEAAAABSAEUAOgAgAFsATAB3AGEA cABwAF0AIABUAGUAcwB0ACwAIABwAGwAZQBhAHMAZQAgAGkAZwBuAG8AcgBlAAAAQAA5AM2PkKH2 LcMBHwA9AAEAAAAKAAAAUgBFADoAIAAAAAAAAgFHAAEAAAA4AAAAYz11czthPSA7cD1CbGFjayBT dG9ybTtsPUJTTi1NQUlMLTAxLTAzMDYwODE5NDYxOVotMjE5NAAfAEkAAQAAADgAAABbAEwAdwBh AHAAcABdACAAVABlAHMAdAAsACAAcABsAGUAYQBzAGUAIABpAGcAbgBvAHIAZQAAAEAATgCAgvbX 9S3DAR8AWgABAAAAHgAAAEQAYQB2AGkAZAAgAEYAcgBhAHMAYwBvAG4AZQAAAAAAAgFbAAEAAAA+ AAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAARGF2aWQgRnJhc2NvbmUAU01UUABkYXZlQGZyYXNj b25lLmNvbQAAAAIBXAABAAAAFwAAAFNNVFA6REFWRUBGUkFTQ09ORS5DT00AAB8AXQABAAAAHgAA AEQAYQB2AGkAZAAgAEYAcgBhAHMAYwBvAG4AZQAAAAAAAgFeAAEAAAA+AAAAAAAAAIErH6S+oxAZ nW4A3QEPVAIAAAAARGF2aWQgRnJhc2NvbmUAU01UUABkYXZlQGZyYXNjb25lLmNvbQAAAAIBXwAB AAAAFwAAAFNNVFA6REFWRUBGUkFTQ09ORS5DT00AAB8AZgABAAAACgAAAFMATQBUAFAAAAAAAB8A ZwABAAAAJAAAAGQAYQB2AGUAQABmAHIAYQBzAGMAbwBuAGUALgBjAG8AbQAAAB8AaAABAAAACgAA AFMATQBUAFAAAAAAAB8AaQABAAAAJAAAAGQAYQB2AGUAQABmAHIAYQBzAGMAbwBuAGUALgBjAG8A bQAAAB8AcAABAAAAOAAAAFsATAB3AGEAcABwAF0AIABUAGUAcwB0ACwAIABwAGwAZQBhAHMAZQAg AGkAZwBuAG8AcgBlAAAAAgFxAAEAAAAbAAAAAcMt9eZHkDIym0PKT6iONJ98Hb8M4QAALaxNAB8A dAABAAAAJgAAAGwAdwBhAHAAcABAAGYAcgBhAHMAYwBvAG4AZQAuAGMAbwBtAAAAAAAfABoMAQAA AB4AAABQAGEAdAAgAFIALgAgAEMAYQBsAGgAbwB1AG4AAAAAAB8AHQ4BAAAAOAAAAFsATAB3AGEA cABwAF0AIABUAGUAcwB0ACwAIABwAGwAZQBhAHMAZQAgAGkAZwBuAG8AcgBlAAAAAgEJEAEAAAB6 BQAAdgUAAAkTAABMWkZ1knzXhgMACgByY3BnMTI1gjIDQ2h0bWwxAzA/AQMB9wqAAqQD4wIAY2jB CsBzZXQwIAcTAoD/EAMAUARWCFUHshHVDlEDAd0Q1zIGAAbDEdUzBEYQ2W8S6xHjCO8J9zsYzw4w NTsR0gxgYwBQCwkBZDM2kxFgC6U0IBACKlwOsr0BkGcU8AqjEeMd6DQU8AA8IURPQ1RZUABFIEhU TUwgUABVQkxJQyAiLSAvL1czQyGARFQiRCCUMy4yIYBFTpwiPh7tHo8jwTE4H/BvIKIjDyQfJpAz HYAlcEV8QUQlzQ7xJu8pbyT0NkEO8DxNRVRBB7BBMSxgPSJHCfAEkGF0RQWwIhLQT05UItBUEyzw BeFFeBDxbmdlPQZSdhMxL0EAkAIgIDYQLjAuNh1wOS4xJyL+Ks8lAzc3H/BUSShUTEUlzjQO8FtM gHdhcHBdIFQHkEh0LCALUGVhETAgqGlnbgWwZSRuNR/w/i8zTzF/JkU0kTeQKE8mnwU7ZDURYDxC T0RZoCBkaXI9O4ByOtDPO0MAIQMwPeFkbwDgPeH5CrFccRiwPeEQ8AMwPkWPEWA6+xzxO/9nOTYf 8HhESVY+GQAAQFc7GTZ2NEOPQKJ3LvAY0AdAbKx5IC0wCYAgLXAgEPH+dDsZAcA+JwqiPicKcSR8 /jAoESHgQ1tJ+EDfQe9C/y9ED0UfUJs6+zgdgCZumGJzcAKAPjgnYQFA/1DfSN9J70r/TA9TL04v Tz/fUm9RX15fIOAtYENWb1d/v1iPWZ9ar1u/XM89QEwgMLBLUVVPLfA9liA1YAZ5NbAuMUFSR0lO EC1SSUcgoDogMPxweCLxPjgKsRACP0U/4/8/oUA/Z18fGxFgcTBoP13fb17vX/9uVz7AaRzSJHw0 TSVRRi3RanBpemrAMldyuwvibjktejJPBRBnrwuAB0AF0AeQczugZXozt3adLBA9MVI+GwuAZQqB r25fVAY9QHK7Ym45RgNhNjpxfB/hL3/6ZkkgRPhhdmlHwIGQNdAFoC0w3x2cHYBv31QzcUFbAMAD EMktcDpkhJBlQANQhQT6LgWgbTUge+98/34Pfx9/gC+MRAZgAjCB34Lvg/dTInUv4S84LwHQMDPK IA4gOnERUE2Fb4Z/f4eFia+Kv4vPjN+N75jEVO+IUI+vkL+EBmw04oi7iZ+fly+YP5lPml+iZUNj m///nQ+D95/foO+h/6MPpB+O9fh1YmoFkI+Ppq+D6DTG/5OvlL+HlDVPGNCoX6lvqn+vtY+2n7ev JNY1clEvd8L/r79WH2KfY69kv7z/bs+yn/dw73R1H/BQbB91mXUPdh/3dy94P3lNdLQxuF+5b7p/ /85fz2/QeXow0S/SP9BMhIT/sa/EX4eUhObUT9Vf0E/a3//b79z/U+9U/+BP4V/ib+N//+SP5Z/m r+e/6M/p3+rv6///7Q/uH+8v8D/xT/Jf82/0f//1j/afgYALgC7gESDXn9ivuYeFdjEwEHohNTBo LvC/BbB6pYgC+w/8H4eFcANgdmN7IQWwLt2v3r/fzF//BV8Gbwc6Al8Db9/MNNP+0//6of8vAD+H hcnwzg8JPwpP/56/Du8P/9/Pq4wskA0TxZAaaBjQZizw+SB0cDo7IYD+4i4SShhj/uBuL/MOohxA Zm8aAAtSbArM0dBpZWxkOxJmHAB6wCm0QHtIIGFSISBOS88hUBgPGR8aLH19zNEcAAMvoDuAXGNm MVx1/24qHZ8erxorwg/IesKfrur+QTgOE+8U/7tfvG8l779v/yt3x5/DS77Qr3HG4cCPr4H/aWct nzG/xA83DzyIy0GvkN89YTM9r2A4z8VBN69xa5AUTUwqYH09gAAAHwA1EAEAAACQAAAAPAA0ADAA MwAwADEANQA4ADEAQgAyADkANgAyAEIANAA0ADgANgA5ADAAQQAwADIAMwBFAEYAMQA2AEQARgBF ADEANQA3AEEAMgAzAEUAQABiAHMAbgAtAG0AYQBpAGwALQAwADEALgBiAHMAdABvAHIAbQBuAGUA dAB3AG8AcgBrAHMALgBjAG8AbQA+AAAAHwBHEAEAAAAeAAAAbQBlAHMAcwBhAGcAZQAvAHIAZgBj ADgAMgAyAAAAAAALAPIQAQAAAB8A8xABAAAATAAAAFIARQAlADMAQQAgAFsATAB3AGEAcABwAF0A IABUAGUAcwB0ACwAIABwAGwAZQBhAHMAZQAgAGkAZwBuAG8AcgBlAC4ARQBNAEwAAAALAPYQAAAA AEAABzDaHvmc9i3DAUAACDCLVJWh9i3DAQMA3j/p/QAAAwDxPwkEAAAfAPg/AQAAAB4AAABQAGEA dAAgAFIALgAgAEMAYQBsAGgAbwB1AG4AAAAAAAIB+T8BAAAAYwAAAAAAAADcp0DIwEIQGrS5CAAr L+GCAQAAAAAAAAAvTz1CTEFDSyBTVE9STS9PVT1GSVJTVCBBRE1JTklTVFJBVElWRSBHUk9VUC9D Tj1SRUNJUElFTlRTL0NOPVBDQUxIT1VOAAAfAPo/AQAAACoAAABTAHkAcwB0AGUAbQAgAEEAZABt AGkAbgBpAHMAdAByAGEAdABvAHIAAAAAAAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GC AQAAAAAAAAAuAAAAAwD9P+QEAAADABlAAAAAAAMAGkAAAAAAAwAdQAAAAAADAB5AAAAAAB8AMEAB AAAAEgAAAFAAQwBBAEwASABPAFUATgAAAAAAHwAxQAEAAAASAAAAUABDAEEATABIAE8AVQBOAAAA AAAfADJAAQAAACQAAABkAGEAdgBlAEAAZgByAGEAcwBjAG8AbgBlAC4AYwBvAG0AAAAfADNAAQAA ACQAAABkAGEAdgBlAEAAZgByAGEAcwBjAG8AbgBlAC4AYwBvAG0AAAAfADhAAQAAABIAAABQAEMA QQBMAEgATwBVAE4AAAAAAB8AOUABAAAABAAAAC4AAAALACkAAAAAAAsAIwAAAAAAAwAGEGVM9VkD AAcQKQEAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABXRVJFQUxMWU5FRURUT0NIQVRQQVRD LS0tLS1PUklHSU5BTE1FU1NBR0UtLS0tLUZST006REFWSURGUkFTQ09ORU1BSUxUTzpEQVZFQEZS QVNDT05FQ09NU0VOVDpTVU42LzgvAAAAAAIBfwABAAAASAAAADw0MDMwMTU4MUIyOTYyQjQ0ODY5 MEEwMjNFRjE2REZFMTU3QTIzRUBic24tbWFpbC0wMS5ic3Rvcm1uZXR3b3Jrcy5jb20+AKaw ------_=_NextPart_001_01C32DF6.A1908FCD-- From lwapp@frascone.com Tue Jun 17 18:06:58 2003 From: lwapp@frascone.com (Pat R. Calhoun) Date: Tue, 17 Jun 2003 10:06:58 -0700 Subject: [Lwapp] Layer 3 LWAPP Message-ID: <40301581B2962B448690A023EF16DFE157A2F2@bsn-mail-01.bstormnetworks.com> All, I attempted to capture some Layer 3 (UDP) transport for LWAPP in the -02 = draft. However, one thing that eludes me is how to do the WLAN switch = discovery at Layer 3. Here are some thoughts that I've come up with, and = would solicit input: 1. Multicast. The use of multicast to discovery WLAN switches across = subnets seems very reasonable, except that all IT managers I've talked = to disable multicast in their networks. 2. DHCP. It is possible to return a vendor specific DHCP extension. One = issue I've heard from a couple of sources is that in some instances DHCP = servers are under the administration of another group from those = responsible for WLAN service, and therefore this cannot be the only way. 3. DNS. Another mechanism, but this one does not necessarily provide = geographical information, and therefore it could cause APs to associate = with WLAN switches that are very far away. Not ideal. 4. Static Config. Certainly a viable method, but not very scalable. 5. SLP. Not much demand for SLP, and it suffers from many of the issues = above. Thoughts? PatC From lwapp@frascone.com Tue Jun 17 22:41:42 2003 From: lwapp@frascone.com (David Molnar) Date: Tue, 17 Jun 2003 17:41:42 -0400 (EDT) Subject: [Lwapp] Replay issue in A.3 rekeying Message-ID: Hi all, I was looking at the draft and I am concerned by the rekey messages in Appendix A.3. There seems to be no protection against replaying an old rekey message. Performing such a replay would allow an adversary to obtain valid encrypted + authenticated commands from the AR addressed to someone else. While I haven't come up with a *practical* scenario where this is a problem, it seems worrisome. Let me illustrate with an example, then I'll talk about a fix. There's an easy fix that comes to mind, but I want to hear what other people think of it. Suppose Alice and Bob are APs, both talking to Charlie, an AR. Alice and Charlie initiate rekeying. Alice sends to Charlie a KEY-UPDATE consisting of a new session key encrypted with Charlie's public key, i.e. C1 = E_C{Kpub, PKCS1(New Alice-Charlie Session Key)} Both Alice and Charlie move to encrypting and authenticating with the new Alice-Charlie session key after Alice receives a KEY-UPDATE-RSP. A ------------------------------> C KEY-UPDATE = {C1, SessionID} A <----------------------------- C KEY-UPDATE-RSP Now suppose Bob *somehow* obtains a copy of Alice's C1 value. I stress that I don't have a practical way for Bob to do this. Because Bob does not know Charlie's private key, he cannot decrypt the rekeying message and learn the new Alice-Charlie session key. The next time Bob rekeys with Charlie, however, he replays to Charlie the rekeying payload C1 from Alice. B ------------------------------> C KEY-UPDATE = {C1, SessionID'} // same as Alice C1 B <----------------------------- C KEY-UPDATE-RSP Because Bob in this scenario knows C1 and there's no tie as far as I can tell between C1 and the sessionID, Bob simply makes up a new SessionID' and puts it in the KEY-UPDATE message. Charlie has no way to tell that the keys are the same based on SessionID alone. Note also that if you ever see the KEY-UPDATE message in the clear, you can just read off C1. As far as I can tell, Charlie will accept the rekey message, send the KEY-UPDATE-RSP, and begin sending Bob control frames encrypted + authenticated with the Alice-Charlie session key. Does that seem right? Bob can't read these commands, but he can *forward them to Alice*. Alice will use the Alice-Charlie session key to decrypt and authenticate these control frames, and the control frames will pass with flying colors. At the same time, Bob can try to manipulate Charlie into sending any command he wants such that it arrives after rekeying with Alice's key, so depending on the implementation, Bob might be able to send arbitrary commands to Alice from Charlie and have her act on them. Bob can do this until Alice rekeys. The quick fix I had in mind was to add the name of the AP to C1. That is, we would have C1 = E_ar{Kpub, PKCS1(KeyMaterial), APName} instead of C1 = E_ar{Kpub, PKCS1(KeyMaterial)}. This would thwart the attack above, because Charlie would reject a rekey message from Alice in the context of Bob's connection. Because LWAPP assumes a PKI in place and certificates, we can say that Charlie "knows" when he is talking to Bob and when he's talking to Alice. In other contexts without certificates in place, this fix probably wouldn't work. Another fix might be to put the SessionID in C1 and force SessionIDs to be globally unique across all APs. That is, C1 = E_ar{Kpub, PKCS1(KeyMaterial), SessionID} instead of C1 = E_ar{Kpub, PKCS1(KeyMaterial)}. Placing SessionID in C1 would thwart the attack above, because the AR would reject a rekey request with the same ID as an already open session. The main downside is if you wanted to have several APs share a session (maybe for clustered configuration?), this would prevent that. So what do people think? Did I miss something? Is this worth fixing? thanks, -David Molnar From lwapp@frascone.com Tue Jun 17 23:54:10 2003 From: lwapp@frascone.com (Scott G. Kelly) Date: Tue, 17 Jun 2003 15:54:10 -0700 Subject: [Lwapp] Replay issue in A.3 rekeying References: Message-ID: <3EEF9C12.3000200@airespace.com> Hi David, Thanks for taking the time to review this. After a quick once over of your email, my first impulse is to emphasize that the control traffic between Alice and Charlie (including the rekey exchange) are encrypted and authenticated with the session keys. So, C1 is encrypted with Charlie's public key *and* with the current session key while in transit. So, how could Bob obtain C1? Either he breaks the session keys under which the rekey message is encrypted, or he somehow compromises the integrity of Alice's or Charlie's runtime memory, or he gets Alice or Charlie to somehow leak C1. This may be possible, but in such cases, might it not also be possible to determine the actual session keys, and even Alice or Charlie's private keys? I guess the problem I have with this line of reasoning is that it seems to go something like "assume the security between Alice and Charlie has been broken - this implies that ....". It seems to presuppose that either the physical security of the devices or the security of the device's private keys, or the security of the session keys has been compromised. I'm not sure that there is *anything* we could add which would make a difference in such cases. On the other hand, assuming that I'm missing something here, your suggested remedy would seem to accomplish a binding, so long as the AP name is securely verifiable (e.g. contained in the AP's cert). An alternative would be for Alice to sign PKCS1(New Alice-Charlie Session Key), and concatenate the signature with this prior to encrypting with Charlie's public key, but I think your method is simpler. So, am I missing something obvious here? Scott David Molnar wrote: > Hi all, > > I was looking at the draft and I am concerned by the rekey messages in > Appendix A.3. There seems to be no protection against replaying an old > rekey message. Performing such a replay would allow an adversary to obtain > valid encrypted + authenticated commands from the AR addressed to someone > else. While I haven't come up with a *practical* scenario where this is a > problem, it seems worrisome. > > Let me illustrate with an example, then I'll talk about a fix. There's an > easy fix that comes to mind, but I want to hear what other people think of > it. > > Suppose Alice and Bob are APs, both talking to Charlie, an AR. > > Alice and Charlie initiate rekeying. Alice sends to Charlie a KEY-UPDATE > consisting of a new session key encrypted with Charlie's public > key, i.e. > C1 = E_C{Kpub, PKCS1(New Alice-Charlie Session Key)} > > Both Alice and Charlie move to encrypting and authenticating with the new > Alice-Charlie session key after Alice receives a KEY-UPDATE-RSP. > > A ------------------------------> C > KEY-UPDATE = {C1, SessionID} > > A <----------------------------- C > KEY-UPDATE-RSP > > Now suppose Bob *somehow* obtains a copy of Alice's C1 value. I stress > that I don't have a practical way for Bob to do this. Because Bob does > not know Charlie's private key, he cannot decrypt the rekeying message and > learn the new Alice-Charlie session key. The next time Bob rekeys with > Charlie, however, he replays to Charlie the rekeying payload C1 from > Alice. > > B ------------------------------> C > KEY-UPDATE = {C1, SessionID'} // same as Alice C1 > > B <----------------------------- C > KEY-UPDATE-RSP > > Because Bob in this scenario knows C1 and there's no tie as far as I can > tell between C1 and the sessionID, Bob simply makes up a new SessionID' > and puts it in the KEY-UPDATE message. Charlie has no way to tell that the > keys are the same based on SessionID alone. Note also that if you ever see > the KEY-UPDATE message in the clear, you can just read off C1. > > As far as I can tell, Charlie will accept the rekey message, send the > KEY-UPDATE-RSP, and begin sending Bob control frames encrypted + > authenticated with the Alice-Charlie session key. Does that seem right? > > Bob can't read these commands, but he can *forward them to Alice*. Alice > will use the Alice-Charlie session key to decrypt and authenticate these > control frames, and the control frames will pass with flying colors. At > the same time, Bob can try to manipulate Charlie into sending any command > he wants such that it arrives after rekeying with Alice's key, so > depending on the implementation, Bob might be able to send arbitrary > commands to Alice from Charlie and have her act on them. Bob can do this > until Alice rekeys. > > The quick fix I had in mind was to add the name of the AP to C1. That is, > we would have > > C1 = E_ar{Kpub, PKCS1(KeyMaterial), APName} > > instead of > C1 = E_ar{Kpub, PKCS1(KeyMaterial)}. > > This would thwart the attack above, because Charlie would reject a rekey > message from Alice in the context of Bob's connection. Because LWAPP > assumes a PKI in place and certificates, we can say that Charlie "knows" > when he is talking to Bob and when he's talking to Alice. In other > contexts without certificates in place, this fix probably wouldn't work. > > Another fix might be to put the SessionID in C1 and force SessionIDs to be > globally unique across all APs. That is, > > C1 = E_ar{Kpub, PKCS1(KeyMaterial), SessionID} > instead of > C1 = E_ar{Kpub, PKCS1(KeyMaterial)}. > > Placing SessionID in C1 would thwart the attack above, because the AR > would reject a rekey request with the same ID as an already open session. > The main downside is if you wanted to have several APs share a session > (maybe for clustered configuration?), this would prevent that. > > So what do people think? Did I miss something? Is this worth fixing? > > thanks, > -David Molnar > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp From lwapp@frascone.com Wed Jun 18 14:53:51 2003 From: lwapp@frascone.com (David Molnar) Date: Wed, 18 Jun 2003 09:53:51 -0400 (EDT) Subject: [Lwapp] Replay issue in A.3 rekeying In-Reply-To: <3EEF9C12.3000200@airespace.com> References: <3EEF9C12.3000200@airespace.com> Message-ID: On Tue, 17 Jun 2003, Scott G. Kelly wrote: Thanks for your quick response! > integrity of Alice's or Charlie's runtime memory, or he gets Alice or > Charlie to somehow leak C1. This may be possible, but in such cases, > might it not also be possible to determine the actual session keys, and > even Alice or Charlie's private keys? I agree that it's a bit far-fetched to think that this might happen in practice. At the same time, I note that the stated rationale for having the rekeying message consist of a session key encrypted with the AR's public key is to provide forward secrecy: "[the C1 message] provides a form of forward secrecy, as an attacker who has broken the current AR-AP session key must also have broken the AR's private RSA key to determine this new value." (appendix A.3, page 57) It looks like the draft is *already* considering a scenario in which the current session key has been broken, yet the AR and even the AP remain physically secure and the new session key cannot just be "read out" by the attacker from a compromised endpoint. Otherwise there would be no point to "forward secrecy" in the draft, since as you point out, the adversary could just read out the new session key. Note that the KEY-UPDATE message, from which C1 can simply be read off, is sent in the current AR-AP session key. Therefore the attacker considered in the draft would have access to C1. I think the setting the draft seems to consider is exactly the setting for the flaw I described. While the flaw doesn't compomise forward secrecy (the adversary doesn't get to read the AP-AR traffic), it does allow for a compromise of control of the AP. In the setting of LWAPP where we are really interested in control messages, this is arguably a more serious issue that simply being able to read the control frames. Am I missing something? > name is securely verifiable (e.g. contained in the AP's cert). An > alternative would be for Alice to sign PKCS1(New Alice-Charlie Session > Key), and concatenate the signature with this prior to encrypting with > Charlie's public key, but I think your method is simpler. Yes, I think having Alice sign the PKCS1 request would be fine as well. I think it might even let Alice get away without needing a certificate, but I need to think about that a bit more. Also you would want to be a little careful with how you do the signature if you're using RSA, since (M^d)^e = M. :) Thanks, -David Molnar From lwapp@frascone.com Wed Jun 18 14:58:20 2003 From: lwapp@frascone.com (Nehru Bhandaru) Date: Wed, 18 Jun 2003 09:58:20 -0400 Subject: [Lwapp] Layer 3 LWAPP In-Reply-To: <40301581B2962B448690A023EF16DFE157A2F2@bsn-mail-01.bstormnetworks.com> Message-ID: <001101c335a1$acbed460$7a0ba8c0@legra.com> One other possibility is to use RADIUS to assist in the discovery process in a scaleable manner. In short, the AP (mutual) authenticates to the radius server and the AR to associate is provided as a result of the authentication process. Perhaps one of the extensions defined in IETF RFC 2868 can be used for this purpose. While the draft defines a session key exchange protocol, it is not clear to me how the AP determines which AR is authorized to associate with it. The radius approach will also solve this problem. - Nehru -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Pat R. Calhoun Sent: Tuesday, June 17, 2003 1:07 PM To: lwapp@frascone.com Subject: [Lwapp] Layer 3 LWAPP All, I attempted to capture some Layer 3 (UDP) transport for LWAPP in the -02 draft. However, one thing that eludes me is how to do the WLAN switch discovery at Layer 3. Here are some thoughts that I've come up with, and would solicit input: 1. Multicast. The use of multicast to discovery WLAN switches across subnets seems very reasonable, except that all IT managers I've talked to disable multicast in their networks. 2. DHCP. It is possible to return a vendor specific DHCP extension. One issue I've heard from a couple of sources is that in some instances DHCP servers are under the administration of another group from those responsible for WLAN service, and therefore this cannot be the only way. 3. DNS. Another mechanism, but this one does not necessarily provide geographical information, and therefore it could cause APs to associate with WLAN switches that are very far away. Not ideal. 4. Static Config. Certainly a viable method, but not very scalable. 5. SLP. Not much demand for SLP, and it suffers from many of the issues above. Thoughts? PatC _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From lwapp@frascone.com Wed Jun 18 15:38:50 2003 From: lwapp@frascone.com (Pat R. Calhoun) Date: Wed, 18 Jun 2003 07:38:50 -0700 Subject: [Lwapp] Layer 3 LWAPP Message-ID: <40301581B2962B448690A023EF16DFE157A31D@bsn-mail-01.bstormnetworks.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C335A7.55305F10 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable One other possibility is to use RADIUS to assist in the discovery process in a scaleable manner. In short, the AP (mutual) authenticates to the radius server and the AR to associate is provided as a result of the authentication process. Perhaps one of the extensions defined in IETF=20 RFC 2868 can be used for this purpose. Ahhh protocol abuse - gotta love it :) Seriously, I don't believe that we should mandate RADIUS for a = protocol like LWAPP. Further, as far as I'm concerned, these APs will be = a great target for hackers to get into a private network, so minimizing = the number of protocols on the device is goodness. While the draft defines a session key exchange protocol, it is not clear to me how the AP determines which AR is authorized to associate with it. The radius approach will also solve this problem. Correct, but all of the approaches I mentioned were intended to = solve this problem. When LWAPP is run at Layer 2 (over ethernet), a = broadcast mechanism is used for discovery. Whether an AP has a = "preferred" AR is an implementation issue.=20 PatC ------_=_NextPart_001_01C335A7.55305F10 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjMOAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAGgAAAFJFOiBbTHdhcHBdIExheWVy IDMgTFdBUFAAwQcBBYADAA4AAADTBwYAEgAHACYAMgADAFQBASCAAwAOAAAA0wcGABIABwAmADIA AwBUAQEJgAEAIQAAADQxMkMwODY3M0FCNUM5NDdBQkIwNDA2QjA5MzY4NEI1AAcHAQOQBgBYCgAA NwAAAAMAJgAAAAAAAwA2AAAAAABAADkAEF8wVac1wwEeAD0AAQAAAAUAAABSRTogAAAAAAIBRwAB AAAAOAAAAGM9dXM7YT0gO3A9QmxhY2sgU3Rvcm07bD1CU04tTUFJTC0wMS0wMzA2MTgxNDM4NTBa LTk2NDAAHgBJAAEAAAAaAAAAUkU6IFtMd2FwcF0gTGF5ZXIgMyBMV0FQUAAAAEAATgAAJrSsoTXD AR4AWgABAAAADwAAAE5laHJ1IEJoYW5kYXJ1AAACAVsAAQAAAD8AAAAAAAAAgSsfpL6jEBmdbgDd AQ9UAgAAAABOZWhydSBCaGFuZGFydQBTTVRQAGJoYW5kYXJ1QGxlZ3JhLmNvbQAAAgFcAAEAAAAY AAAAU01UUDpCSEFOREFSVUBMRUdSQS5DT00AHgBdAAEAAAAPAAAATmVocnUgQmhhbmRhcnUAAAIB XgABAAAAPwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAE5laHJ1IEJoYW5kYXJ1AFNNVFAAYmhh bmRhcnVAbGVncmEuY29tAAACAV8AAQAAABgAAABTTVRQOkJIQU5EQVJVQExFR1JBLkNPTQAeAGYA AQAAAAUAAABTTVRQAAAAAB4AZwABAAAAEwAAAGJoYW5kYXJ1QGxlZ3JhLmNvbQAAHgBoAAEAAAAF AAAAU01UUAAAAAAeAGkAAQAAABMAAABiaGFuZGFydUBsZWdyYS5jb20AAB4AcAABAAAAFgAAAFtM d2FwcF0gTGF5ZXIgMyBMV0FQUAAAAAIBcQABAAAAGwAAAAHDNaHKc9W2Elb6J0wSnDPT19UeZXQA AOxExgAeAHQAAQAAABMAAABsd2FwcEBmcmFzY29uZS5jb20AAB4AGgwBAAAADwAAAFBhdCBSLiBD YWxob3VuAAAeAB0OAQAAABYAAABbTHdhcHBdIExheWVyIDMgTFdBUFAAAAACAQkQAQAAAOkDAADl AwAAnAUAAExaRnVytAhbAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/ CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFAz CwkBZDM2FlALpiBPQG5lIG90aBKBcBJvBBBpYgMQaXR5giAEACB0byB1FBBhB/BBRElVBfAegWH9 HbFzBUALgB5wHVAKogqAtmQEAAWgdgSQHjBwA2DOYweQBCAgAWEgBPAHQDZlAaAiYCADgR0Aci6k IEkDoHNoF8EsICgAQVAgKG11dHV9B0ApH4Ak0B1QAjAN4GHHDrAeYx1BIHJhIMAesE8iIASQIREf gG5kJkNB/lIgZB9kIYAHMA6wHkIhYXx2aQEAJ5AfkCIBGCBzZHVsBUBvZiZDJUlpbwIgIGQhZSMw UASQE+Bw/wQgAiAdESrUDsEJ8ACQAiAfBCABAQuAKdEgAUlFVAZGCuMKgFJGQyAysDg2OCAiQAOg Yh0Q/x6xJ5ACEAXAHUApQghwHZEMZS4gZCBkPFBSQ/o+EMBoM9AhUh6AF5EfgGJiHrItIGcdMAGQ IM8XsCEQHkAFQDopMq8GU9EIYHNseSPQSS7QAiDuJwVAMRAeAGU1oR1AJdB8IHcdECOBKoAnkAOB ZL8pAh71MZIiEDQXHgBrHRDUTFckgFAjMEYIcB1CGyPQKgFmCsEqAUknbf8wwAIgIZAEoAmAI9Me wSSA+wQgA/BsAyAxESIQCcE5EbkBkHJnFCAxgxPgYzvgPxQAHnJAcguAH2IhUWl20ykCHQB0dwWw ayPQKMCnIsALgAdwaXoLgGcmQ/xudQbQEoEqwTQWLWImQ/8BACmgIZAeQjUgBHAdACzB/TYqVzHg IqFF8yaQAYAu1f8qEhQQHbFFwTvgHjAOwBPRf0QQHRA0FiPQHhAgZB5Rbv8dMDDAImExsUNxHRAj kAfgbyezJJABAA6wckORB5F3/zHgE9An4R5CJUIFsEPgCYC/KB8dEAPwHUA1wSMwVCZo/y1AIWEA 0DPwP0MHQENhKMC+bCEQUCUx4wNgIpFtMp/rM6AIUHIYIGMjwTSwBUD/B0ADICrGUqUHkTfwB4Al kf8tgSeQOUAYIEHSCfApwh6B91PDMcVU1SBIIAnwPAQeQoxydSHxBUBMYXkSgb0UQCghAi4gHUJC 0Sk88fsxAFLBZCJAH9EHgEqiBAD/PdAeUTFHIMdbgx1DA5EkgXsT4CoSIiFgARAEkBghIv9PFgOg B3ALUFUQJYErwx5BrypwMoAv1SBkUCXQQyBkAn1msAAAAB4ANRABAAAASAAAADw0MDMwMTU4MUIy OTYyQjQ0ODY5MEEwMjNFRjE2REZFMTU3QTMxREBic24tbWFpbC0wMS5ic3Rvcm1uZXR3b3Jrcy5j b20+AB4ARxABAAAADwAAAG1lc3NhZ2UvcmZjODIyAAALAPIQAQAAAB8A8xABAAAAQAAAAFIARQAl ADMAQQAgAFsATAB3AGEAcABwAF0AIABMAGEAeQBlAHIAIAAzACAATABXAEEAUABQAC4ARQBNAEwA AAALAPYQAAAAAEAABzD6kYV7pTXDAUAACDBn1EVVpzXDAQMA3j/kBAAAAwDxPwkEAAAeAPg/AQAA AA8AAABQYXQgUi4gQ2FsaG91bgAAAgH5PwEAAABjAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAA AAAAAC9PPUJMQUNLIFNUT1JNL09VPUZJUlNUIEFETUlOSVNUUkFUSVZFIEdST1VQL0NOPVJFQ0lQ SUVOVFMvQ049UENBTEhPVU4AAB4A+j8BAAAAFQAAAFN5c3RlbSBBZG1pbmlzdHJhdG9yAAAAAAIB +z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAAAwD9P+QEAAADABlAAAAA AAMAGkAAAAAAAwAdQAAAAAADAB5AAAAAAB4AMEABAAAACQAAAFBDQUxIT1VOAAAAAB4AMUABAAAA CQAAAFBDQUxIT1VOAAAAAB4AMkABAAAAEwAAAGJoYW5kYXJ1QGxlZ3JhLmNvbQAAHgAzQAEAAAAT AAAAYmhhbmRhcnVAbGVncmEuY29tAAAeADhAAQAAAAkAAABQQ0FMSE9VTgAAAAAeADlAAQAAAAIA AAAuAAAACwApAAAAAAALACMAAAAAAAMABhC4mbanAwAHEGcDAAADABAQAAAAAAMAERAAAAAAHgAI EAEAAABlAAAAT05FT1RIRVJQT1NTSUJJTElUWUlTVE9VU0VSQURJVVNUT0FTU0lTVElOVEhFRElT Q09WRVJZUFJPQ0VTU0lOQVNDQUxFQUJMRU1BTk5FUklOU0hPUlQsVEhFQVAoTVVUVUFMKQAAAAAC AX8AAQAAAEgAAAA8NDAzMDE1ODFCMjk2MkI0NDg2OTBBMDIzRUYxNkRGRTE1N0EzMURAYnNuLW1h aWwtMDEuYnN0b3JtbmV0d29ya3MuY29tPgDgjQ== ------_=_NextPart_001_01C335A7.55305F10-- From lwapp@frascone.com Wed Jun 18 16:28:03 2003 From: lwapp@frascone.com (Rohit Suri) Date: Wed, 18 Jun 2003 08:28:03 -0700 Subject: [Lwapp] Layer 3 LWAPP Message-ID: <40301581B2962B448690A023EF16DFE11D834F@bsn-mail-01.bstormnetworks.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C335AE.35C261F8 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Also one more issue with RADIUS is that this requires configuration of = radius server on the AP, which again comes back to static configuration = on AP's. Rohit -----Original Message----- From: Pat R. Calhoun on behalf of Pat R. Calhoun Sent: Wed 6/18/2003 7:38 AM To: lwapp@frascone.com Cc:=09 Subject: RE: [Lwapp] Layer 3 LWAPP One other possibility is to use RADIUS to assist in the discovery process in a scaleable manner. In short, the AP (mutual) authenticates to the radius server and the AR to associate is provided as a result of the authentication process. Perhaps one of the extensions defined in IETF=20 RFC 2868 can be used for this purpose. Ahhh protocol abuse - gotta love it :) Seriously, I don't believe that we should mandate RADIUS for a = protocol like LWAPP. Further, as far as I'm concerned, these APs will be = a great target for hackers to get into a private network, so minimizing = the number of protocols on the device is goodness. While the draft defines a session key exchange protocol, it is not clear to me how the AP determines which AR is authorized to associate with it. The radius approach will also solve this problem. Correct, but all of the approaches I mentioned were intended to = solve this problem. When LWAPP is run at Layer 2 (over ethernet), a = broadcast mechanism is used for discovery. Whether an AP has a = "preferred" AR is an implementation issue.=20 PatC ------_=_NextPart_001_01C335AE.35C261F8 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgUPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAGgAAAFJFOiBbTHdhcHBdIExheWVy IDMgTFdBUFAAwQcBBYADAA4AAADTBwYAEgAIABwAAwADABwBASCAAwAOAAAA0wcGABIACAAcAAQA AwAdAQEJgAEAIQAAADgwRUU5NjYxMzhFOEZDNEFCREE4QkJCNzM5RjJFRjhFAJYHAQOQBgCkCwAA NwAAAAMAJgAAAAAAAwA2AAAAAABAADkA+GHCNa41wwEeAD0AAQAAAAUAAABSRTogAAAAAAIBRwAB AAAAOAAAAGM9dXM7YT0gO3A9QmxhY2sgU3Rvcm07bD1CU04tTUFJTC0wMS0wMzA2MTgxNTI4MDNa LTk3NTYAHgBJAAEAAAAaAAAAUkU6IFtMd2FwcF0gTGF5ZXIgMyBMV0FQUAAAAEAATgAQXzBVpzXD AR4AWgABAAAADwAAAFBhdCBSLiBDYWxob3VuAAACAVsAAQAAAEUAAAAAAAAAgSsfpL6jEBmdbgDd AQ9UAgAAAABQYXQgUi4gQ2FsaG91bgBTTVRQAGx3YXBwLWFkbWluQGZyYXNjb25lLmNvbQAAAAAC AVwAAQAAAB4AAABTTVRQOkxXQVBQLUFETUlOQEZSQVNDT05FLkNPTQAAAB4AXQABAAAADwAAAFBh dCBSLiBDYWxob3VuAAACAV4AAQAAAGMAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089 QkxBQ0sgU1RPUk0vT1U9RklSU1QgQURNSU5JU1RSQVRJVkUgR1JPVVAvQ049UkVDSVBJRU5UUy9D Tj1QQ0FMSE9VTgAAAgFfAAEAAABKAAAARVg6L089QkxBQ0sgU1RPUk0vT1U9RklSU1QgQURNSU5J U1RSQVRJVkUgR1JPVVAvQ049UkVDSVBJRU5UUy9DTj1QQ0FMSE9VTgAAAB4AZgABAAAABQAAAFNN VFAAAAAAHgBnAAEAAAAZAAAAbHdhcHAtYWRtaW5AZnJhc2NvbmUuY29tAAAAAB4AaAABAAAABQAA AFNNVFAAAAAAHgBpAAEAAAAXAAAAcGNhbGhvdW5AYWlyZXNwYWNlLmNvbQAAHgBwAAEAAAAWAAAA W0x3YXBwXSBMYXllciAzIExXQVBQAAAAAgFxAAEAAAAgAAAAAcM1ocpz1bYSVvonTBKcM9PX1R5l dAAA7ETGAAIlqhoeAHQAAQAAABMAAABsd2FwcEBmcmFzY29uZS5jb20AAB4AGgwBAAAACwAAAFJv aGl0IFN1cmkAAB4AHQ4BAAAAFgAAAFtMd2FwcF0gTGF5ZXIgMyBMV0FQUAAAAAIBCRABAAAA1QQA ANEEAAA1BwAATFpGddbjJEsDAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAE Vj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMA UPMLCQFkMzYWUAumCuMKgCBBbHNvIAIgZSBbBGAYICAEAQpQIAPwdMJoB/BBRElVBfAEAHogHrBh BUAesB9RGCBxHHVpGCAEIAWgbmZptmcIcB+gaQIgHZBmIBAwYWRpdQQgFBBydo8SgSFhHrAdwEFQ LB6A4x/gE9AgYWcLcSChB4LaYgDQax9wHYBzAZAhQI5jIK4DoCMQJ3MuHPRXHPQIAB/gdCbKLSiS T70FEGcLgAdABdAHkHMjsFZlKJMc9EYDYToMgiCyUB+hUi4SIAdAaAhg6SYjYmUT4GwhoCGRKzwv HPQGYAIwKtRXCYAgNhAvMTgvAdAwMyBQNzozOBDATRz0VAJvKtRsd2FwcEBtA1BhBPAdoS4kERz0 Q8ZjKtQt1XViagWQLmVAUkU6IFtMMRJdMCBMYXkSgS+QTFfVIxBQHPRPHbFvItEFwGRwbwQQaWID EB6gef8fQx2AIgAdwB7lJMExgACQ/yTwHiAisxz0IeAxkSJhN2BacANgYymBOSJhIiBjfQdAZQGg O5Ad0ABwHbBy9SuASQOgcyvQACAjMDlngSMQIChtdXR1B0D+KSOgPgAi4AIwDeAfoAeRvyTBItIh zABwLvAi01Ic9D84lDqwBzAOsB9COpF2aZ8BAC7wMYA7MSBxdWwFQH8hkSLSPnkhURz0OpUrgFD7 BJAT4HAEIB2iQ/UOwQnwfwCQAiAEIAEBC4Au4SPhSQhFVEYc5VJGQyD4Mjg2L+A7cCwyN9Iu8PcC EAXAH9NwCHA2wTHQJsqgPFBSQz4QwGhNAC86giTAF5EjoGI34i0gfmc2YAGQMPA6MR4gBUA6jilL 3wZTCGBzbHkjMHZJSAACICcFQCxQNzBl+07RH4N3HcA8sUOwLvADgX5kQjIe5UrCO0BNRzcwa/cd wDVzK4BGCHA2ciMwQzHGZgrBQzFJJ20gojrAfwSgCYA9AzfxIxAEIAPwbP8DIEpBO0AJwR+iCsAp wAVA/0rCE+AkkASQN5NZoguAOJKZOoFpdkIyHbB0dwWwNmsjMB1xbQuAB3BpeuULgGciw251BtAi ciGg/01GRpIiwwEAQtA6wB9CTlDvBHAdsEXxJspXH+A70V8j/yEgAYBIBUNCFBA24SFhVRD/N2AO wBPRXUAdwE1GIzAntv0fUW42YCCgO5FK4VyhHcDfK9AH4CLUSAEOsHJcwQeR/yNUQSAfQj5yBbBd EAmAQU/3HnUeoCuAVD+YMSEDYADQ3x7AWHMHQB1xHXBsImBpVXdLEwNgO8FtS89M0AhQcv8YIDOw IzBN4AVAB0ADIEP2/2vVB5FRIAeAPsEdoS7wUnD/HgICMAnwQvIkwm0CSvVuBe8uwD6hNWQfQnIr 8R+hNPS9FEAoOjJHUDZyXAEpViH7JGBr8WQ7cDkBB4Bj0gQA/1cAH1FKdzn3dLM2cwORPbF7E+BD QiI6kAEQBJAYISL/aEYDoAdwC1BuQC5BITQeM1crgCbKKzFDJsp9gEAAAAAeADUQAQAAAEgAAAA8 NDAzMDE1ODFCMjk2MkI0NDg2OTBBMDIzRUYxNkRGRTExRDgzNEZAYnNuLW1haWwtMDEuYnN0b3Jt bmV0d29ya3MuY29tPgAeAEcQAQAAAA8AAABtZXNzYWdlL3JmYzgyMgAACwDyEAEAAAAfAPMQAQAA AEAAAABSAEUAJQAzAEEAIABbAEwAdwBhAHAAcABdACAATABhAHkAZQByACAAMwAgAEwAVwBBAFAA UAAuAEUATQBMAAAACwD2EAAAAABAAAcwBR4sEq41wwFAAAgwKsPjNa41wwEDAN4/5AQAAAMA8T8J BAAAHgD4PwEAAAALAAAAUm9oaXQgU3VyaQAAAgH5PwEAAABgAAAAAAAAANynQMjAQhAatLkIACsv 4YIBAAAAAAAAAC9PPUJMQUNLIFNUT1JNL09VPUZJUlNUIEFETUlOSVNUUkFUSVZFIEdST1VQL0NO PVJFQ0lQSUVOVFMvQ049UlNVUkkAHgD6PwEAAAAVAAAAU3lzdGVtIEFkbWluaXN0cmF0b3IAAAAA AgH7PwEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC4AAAADAP0/5AQAAAMAGUAA AAAAAwAaQAAAAAADAB1AAAAAAAMAHkAAAAAAHgAwQAEAAAAGAAAAUlNVUkkAAAAeADFAAQAAAAYA AABSU1VSSQAAAB4AMkABAAAAGQAAAGx3YXBwLWFkbWluQGZyYXNjb25lLmNvbQAAAAAeADNAAQAA AAkAAABQQ0FMSE9VTgAAAAAeADhAAQAAAAYAAABSU1VSSQAAAB4AOUABAAAAAgAAAC4AAAALACkA AAAAAAsAIwAAAAAAAwAGEO3k3PoDAAcQbwQAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABB TFNPT05FTU9SRUlTU1VFV0lUSFJBRElVU0lTVEhBVFRISVNSRVFVSVJFU0NPTkZJR1VSQVRJT05P RlJBRElVU1NFUlZFUk9OVEhFQVAsV0hJQ0hBR0FJTkNPTUVTQkFDS1RPAAAAAAIBfwABAAAASAAA ADw0MDMwMTU4MUIyOTYyQjQ0ODY5MEEwMjNFRjE2REZFMTFEODM0RkBic24tbWFpbC0wMS5ic3Rv cm1uZXR3b3Jrcy5jb20+ABUR ------_=_NextPart_001_01C335AE.35C261F8-- From lwapp@frascone.com Wed Jun 18 18:16:24 2003 From: lwapp@frascone.com (Scott G. Kelly) Date: Wed, 18 Jun 2003 10:16:24 -0700 Subject: [Lwapp] Replay issue in A.3 rekeying References: <3EEF9C12.3000200@airespace.com> Message-ID: <3EF09E68.8080102@airespace.com> Hi David, Comments below... David Molnar wrote: > > On Tue, 17 Jun 2003, Scott G. Kelly wrote: > > Thanks for your quick response! > > >>integrity of Alice's or Charlie's runtime memory, or he gets Alice or >>Charlie to somehow leak C1. This may be possible, but in such cases, >>might it not also be possible to determine the actual session keys, and >>even Alice or Charlie's private keys? > > > I agree that it's a bit far-fetched to think that this might happen in > practice. At the same time, I note that the stated rationale for having > the rekeying message consist of a session key encrypted with the AR's > public key is to provide forward secrecy: > > "[the C1 message] provides a form of > forward secrecy, as an attacker who has broken the current AR-AP > session key must also have broken the AR's private RSA key to > determine this new value." (appendix A.3, page 57) > > It looks like the draft is *already* considering a scenario in which the > current session key has been broken, yet the AR and even the AP remain > physically secure and the new session key cannot just be "read out" by the > attacker from a compromised endpoint. Otherwise there would be no point to > "forward secrecy" in the draft, since as you point out, the adversary > could just read out the new session key. Yes, you are right - the FS property does presuppose that the existing session keys have been compromised. And taking this a step further, assuming that they have, then having a way to replay the rekey message (with the same session keys in it) has obvious implications, since the attacker already knows the keys. Rohit points out in a private email that the draft does not accurately depict our current implementation, and that the AP sends the nonce and request to the AR, and that the AR generates the key material and sends it back encrypted with the APs public key, and signed by the AR. In this case, I'm wondering whether your attack can be inverted - but I need to think about this some more. My understanding is that the AP sends a nonce in the JoinRequest, the AR gens the key material, and a concatenation of the nonce and encrypted key material are signed by the AR. Seems like this prevents the inversion, but I'm working quickly here. Scott From lwapp@frascone.com Wed Jun 18 20:11:53 2003 From: lwapp@frascone.com (Nehru Bhandaru) Date: Wed, 18 Jun 2003 15:11:53 -0400 Subject: [Lwapp] Replay issue in A.3 rekeying In-Reply-To: <3EF09E68.8080102@airespace.com> Message-ID: <002801c335cd$7a2e7a60$7a0ba8c0@legra.com> Is PFS (forward secrecy) the only issue here? If the session keys are compromised the attacker can make an AP (or Alice) do some undesirable operations - since the attacker can generate any other protocol message in the current session - e.g change a mobile key. It seems to me what the protocol needs is a replay protection. The scheme of encrypting the key material with target (AP) public key and signing by the originator (AR) should provide the needed authentication for the exchange. However the response from AR can be replayed - in the least causing a denial of service. IMO a key sequence/replay counter should be incorporated into this scheme so the receiver can at least ignore replays. One a more general note, why not leverage key exchanges imminently prevalent (:-)) or prevalent protocols such as 802.11i key exchanges or use TLS since certificates are used for these security schemes anyway. My two cents... - Nehru -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Scott G. Kelly Sent: Wednesday, June 18, 2003 1:16 PM To: lwapp@frascone.com Subject: Re: [Lwapp] Replay issue in A.3 rekeying Hi David, Comments below... David Molnar wrote: > > On Tue, 17 Jun 2003, Scott G. Kelly wrote: > > Thanks for your quick response! > > >>integrity of Alice's or Charlie's runtime memory, or he gets Alice or >>Charlie to somehow leak C1. This may be possible, but in such cases, >>might it not also be possible to determine the actual session keys, >>and even Alice or Charlie's private keys? > > > I agree that it's a bit far-fetched to think that this might happen in > practice. At the same time, I note that the stated rationale for > having the rekeying message consist of a session key encrypted with > the AR's public key is to provide forward secrecy: > > "[the C1 message] provides a form of > forward secrecy, as an attacker who has broken the current AR-AP > session key must also have broken the AR's private RSA key to > determine this new value." (appendix A.3, page 57) > > It looks like the draft is *already* considering a scenario in which > the current session key has been broken, yet the AR and even the AP > remain physically secure and the new session key cannot just be "read > out" by the attacker from a compromised endpoint. Otherwise there > would be no point to "forward secrecy" in the draft, since as you > point out, the adversary could just read out the new session key. Yes, you are right - the FS property does presuppose that the existing session keys have been compromised. And taking this a step further, assuming that they have, then having a way to replay the rekey message (with the same session keys in it) has obvious implications, since the attacker already knows the keys. Rohit points out in a private email that the draft does not accurately depict our current implementation, and that the AP sends the nonce and request to the AR, and that the AR generates the key material and sends it back encrypted with the APs public key, and signed by the AR. In this case, I'm wondering whether your attack can be inverted - but I need to think about this some more. My understanding is that the AP sends a nonce in the JoinRequest, the AR gens the key material, and a concatenation of the nonce and encrypted key material are signed by the AR. Seems like this prevents the inversion, but I'm working quickly here. Scott _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From lwapp@frascone.com Wed Jun 18 20:46:40 2003 From: lwapp@frascone.com (Rohit Suri) Date: Wed, 18 Jun 2003 12:46:40 -0700 Subject: [Lwapp] Replay issue in A.3 rekeying Message-ID: <40301581B2962B448690A023EF16DFE11D8351@bsn-mail-01.bstormnetworks.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C335D2.56418CBE Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sequence Number is already defined in the protocol, This is used to = prevent the replay attacks. Rohit -----Original Message----- From: Nehru Bhandaru [mailto:bhandaru@legra.com] Sent: Wed 6/18/2003 12:11 PM To: lwapp@frascone.com Cc:=09 Subject: RE: [Lwapp] Replay issue in A.3 rekeying Is PFS (forward secrecy) the only issue here? If the session keys are compromised the attacker can make an AP (or Alice) do some undesirable operations - since the attacker can generate any other protocol message in the current session - e.g change a mobile key.=20 It seems to me what the protocol needs is a replay protection. The scheme of encrypting the key material with target (AP) public key and signing by the originator (AR) should provide the needed authentication for the exchange. However the response from AR can be replayed - in the least causing a denial of service. IMO a key sequence/replay counter=20 should be incorporated into this scheme so the receiver=20 can at least ignore replays. One a more general note, why not leverage key exchanges imminently prevalent (:-)) or prevalent protocols such as 802.11i key exchanges or use TLS since certificates are used for these security schemes anyway. My two cents... - Nehru=20 -----Original Message----- From: lwapp-admin@frascone.com=20 [mailto:lwapp-admin@frascone.com] On Behalf Of Scott G. Kelly Sent: Wednesday, June 18, 2003 1:16 PM To: lwapp@frascone.com Subject: Re: [Lwapp] Replay issue in A.3 rekeying Hi David, Comments below... David Molnar wrote: >=20 > On Tue, 17 Jun 2003, Scott G. Kelly wrote: >=20 > Thanks for your quick response! >=20 >=20 >>integrity of Alice's or Charlie's runtime memory, or he gets Alice or=20 >>Charlie to somehow leak C1. This may be possible, but in such cases,=20 >>might it not also be possible to determine the actual session keys,=20 >>and even Alice or Charlie's private keys? >=20 >=20 > I agree that it's a bit far-fetched to think that this might=20 happen in=20 > practice. At the same time, I note that the stated rationale for=20 > having the rekeying message consist of a session key encrypted with=20 > the AR's public key is to provide forward secrecy: >=20 > "[the C1 message] provides a form of > forward secrecy, as an attacker who has broken the current AR-AP > session key must also have broken the AR's private RSA key to > determine this new value." (appendix A.3, page 57) >=20 > It looks like the draft is *already* considering a scenario in which=20 > the current session key has been broken, yet the AR and even the AP=20 > remain physically secure and the new session key cannot just be "read=20 > out" by the attacker from a compromised endpoint. Otherwise there=20 > would be no point to "forward secrecy" in the draft, since as you=20 > point out, the adversary could just read out the new session key. Yes, you are right - the FS property does presuppose that the existing=20 session keys have been compromised. And taking this a step further,=20 assuming that they have, then having a way to replay the rekey message=20 (with the same session keys in it) has obvious implications, since the=20 attacker already knows the keys. Rohit points out in a private email that the draft does not accurately=20 depict our current implementation, and that the AP sends the nonce and=20 request to the AR, and that the AR generates the key material and sends=20 it back encrypted with the APs public key, and signed by the=20 AR. In this=20 case, I'm wondering whether your attack can be inverted - but I need to=20 think about this some more. My understanding is that the AP sends a nonce in the=20 JoinRequest, the AR=20 gens the key material, and a concatenation of the nonce and encrypted=20 key material are signed by the AR. Seems like this prevents the=20 inversion, but I'm working quickly here. Scott _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp ------_=_NextPart_001_01C335D2.56418CBE Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IikTAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAKQAAAFJFOiBbTHdhcHBdIFJlcGxh eSBpc3N1ZSBpbiBBLjMgcmVrZXlpbmcAug0BBYADAA4AAADTBwYAEgAMAC4AKAADAFcBASCAAwAO AAAA0wcGABIADAAuACgAAwBXAQEJgAEAIQAAADI1MTlDMkIzREJGMUVFNEU4REI2MTUyQkRCQURB REQ1AJIHAQOQBgB8EAAANwAAAAMAJgAAAAAAAwA2AAAAAABAADkAvoxBVtI1wwEeAD0AAQAAAAUA AABSRTogAAAAAAIBRwABAAAAOQAAAGM9dXM7YT0gO3A9QmxhY2sgU3Rvcm07bD1CU04tTUFJTC0w MS0wMzA2MTgxOTQ2NDBaLTEwMDkxAAAAAB4ASQABAAAAKQAAAFJFOiBbTHdhcHBdIFJlcGxheSBp c3N1ZSBpbiBBLjMgcmVrZXlpbmcAAAAAQABOAIAiIHrNNcMBHgBaAAEAAAAPAAAATmVocnUgQmhh bmRhcnUAAAIBWwABAAAAPwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAE5laHJ1IEJoYW5kYXJ1 AFNNVFAAYmhhbmRhcnVAbGVncmEuY29tAAACAVwAAQAAABgAAABTTVRQOkJIQU5EQVJVQExFR1JB LkNPTQAeAF0AAQAAAA8AAABOZWhydSBCaGFuZGFydQAAAgFeAAEAAAA/AAAAAAAAAIErH6S+oxAZ nW4A3QEPVAIAAAAATmVocnUgQmhhbmRhcnUAU01UUABiaGFuZGFydUBsZWdyYS5jb20AAAIBXwAB AAAAGAAAAFNNVFA6QkhBTkRBUlVATEVHUkEuQ09NAB4AZgABAAAABQAAAFNNVFAAAAAAHgBnAAEA AAATAAAAYmhhbmRhcnVAbGVncmEuY29tAAAeAGgAAQAAAAUAAABTTVRQAAAAAB4AaQABAAAAEwAA AGJoYW5kYXJ1QGxlZ3JhLmNvbQAAHgBwAAEAAAAlAAAAW0x3YXBwXSBSZXBsYXkgaXNzdWUgaW4g QS4zIHJla2V5aW5nAAAAAAIBcQABAAAAGwAAAAHDNc2Oc0qgHzAoRU+whppIYdGvg0sAASOtLgAe AHQAAQAAABMAAABsd2FwcEBmcmFzY29uZS5jb20AAB4AGgwBAAAACwAAAFJvaGl0IFN1cmkAAB4A HQ4BAAAAJQAAAFtMd2FwcF0gUmVwbGF5IGlzc3VlIGluIEEuMyByZWtleWluZwAAAAACAQkQAQAA ANIJAADOCQAALRMAAExaRnWdycL7AwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP 8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREi DGBjAFDzCwkBZDM2FlALpgrjCoSLCoAGYHEKUG5jZQewbnUG0BKBBAAgB0AYIGH4ZHkgAQELgAmA HqADoJR0aB4gcANgdG8XkbAsIFRoHrEesXUUEOcfwCCAIEFldgnwBUAgEjcYIAtRH0BhAkAA0Gtz ri4c+ggAIQB0HPotJXJ6TwUQZwuAB0AF0AeQc1hhZ2Ulcxz0RgNhOoMMggexaHJ1IEIT4OxuZArA KFBbAMADECCARDpiKIVAbGUJwGFyLgWgbV0dVgIwJ7RXQR+xNi8xOC8B0DAEMyAOIDoxMSBQGk0c 9FQpYCfDbHdhaHBwQANQYQTwAiBlMypiHPRDYye0HVV1YkZqBZArRVJFOijwTH0uAl0H8CLEBAEK UB/SQUYuLHAYIGtleQuAZ6Uc+kkEIFBGBfAoAhB2ci4ACyAgFBAFAAWQeXYpIAMCIGwyNiAgGCA/ uCBJZiADFBAEEGkCIG8c9DNBHsEYICAqcSBRbd8EACGSICEjJBKBYwORAMA3M0Ae0DLBUDTABbFB bKUN4GU10GRvHPRzA3DtHiB1KKAHkGkqQAJgNhHecASQIyA38QQgLTVQC4DfHhE53yagH6A+AWUc 9ABwfx9AIHA24SBHOtAmZB/WY78IcBggIkE3tT5xLsBnOQDPKIEmoECVOtBvYgMQHiCVM0EuHOtJ Q3JlbQQg+yHBPOF3E+AiVEGXH6AJgP8hI0UwIrUgUjCRN/EjlSDwPzeRE9BHIDYRN1Ad8XJ5/wUw M3EgAzNBOtEOsAciR7C9JJBoIAAKwCagBUAoO2D6KRz0cDBgO+FM0yiRPpH2ZwMATHFiH0A18yXU IIBLBcBOcFI10HNoCGBs8x/AIFF2aQEAHPQgEkjieR+xYXUgEQIwDeA+EyAfNOEgAw7ARHRF8Ehv d88iEVTzHPQYIHNwPkEeIPsDUhDAUjqTHnAipR+xPoD/H+UqEC5wBUA6oCFwM3dFMN8BAAMAJiFL wRQQclKQHhDxRfBJTU9JYUziFBAd1P4vIrUFoD0QTUEc5VH1WFH/PrEFsFcwQFIfwiHBIBAese9L VTzAImUeEGlWMhz0OqK/R+FZpFARBbAiliOMTx+g/0lhBGA44UAUSMFKISDQR8B/H0BmMVmRVjFC YkziVVZz/xz0B3A5cB+gAjA2USHyB0DhIjIoOi0pNdAFsWmINyBWYJEa0GhAlQQgODD0Mi4swGln nGpyIXEg4P5MBfA+pB4QACAGkFRSaFa/ONIhc1TVV2E1YQhxdFyhv0tjHsFBAC4AReAc+k1Qkf53 IdAeEAIwI4B0gCS7KAXfHPokvyXPJt0t5C0fIGjx/y5LHOUpBnnfLqUxwGUAKGDXKCAHQDdQTzdQ UwWgAkDEIEdF8EtlbDZQKrmrK6IfoHMosHkg0Eo9EN8eICwQINAsRCywNizqLe9/LvYwVjHRMU8y XzNuHPRI6W0gRGFSkSwc+ghQaOD3dEJYQRewd3SNiNMF0Abwu3gQBcB3ShInsB0DPhzlm41QfeFU ClAg0DE3gPL/gYMg0H68jI+NFCDwAHAjcLVUw3kIYSAd0A3gayKh7VckIYz+jPU+YBEqIXHS60vB O9MnbgNDE+E74JYS/yhAVDE84QeAZWGA0QWxICH/TjEQsTvianKUhpaFIbI8ws9SAAfgWaGS0EMx RfAg838AwB9AWFFXMDfRPZEg0GL/U/Af0mvyOpE3sSDQlIY5cPxnaGMxBUBm0gdAYSGcOb8hsgEA TUFo8j70MKB1eCH/Q5Y4gp4YT8IiEpjIloggULdh0EBhooM/k4+NBUke0P8JwiABR+EkkJYhRTBF cAVA8mYKwC1mFCBLYSGjYGH/kcCn9GBjnrQc9BPggyCj0d8f4Yz2IFChoVvTQSJUeID/POGXUiDQ p4BmMqpGN5EBkP9f0j4EacFUw4z2E+BSkEx1/4cGQhcukQCQWdFLwUUwohn/S+YfsU2zjPYgElGw pQJPKH8esSHDUoNUwjUakI+6NCL+WyASm2BCFoWgUmVJUjTh/1fAS8C5zDTtINBskWKTOjX/R8Ah 0BPgimEDYIcgQrxRsO4tO2C5zLP6bSFwn2WxYY8eIMBJtmSlRVJTQUzT/yCAucygyh6xH6AH4Gmx ClCMLiI0wKvDZGl4hrLnINAKsEJxNTdOpabpYtG+b8BgBCA74DsBIBJkKkDrAYAeoioe5SqzFASB TGL/s9F0MQrAN/Af0kfADeC1jP9DHkziwAMJ4cA1INBY0CJU/1fho3e2IztwjPYYICkRA6D+cGag DdEHQDZRcYM7Ejm0b8hCs/o6oWbSasNyWFEi9x8CjWcIYHTI4FCFOhdXk79FMDkayUFXMGARRfBP QUL/A/E+4zjhjPZ0AF7VY3CcUftgESGyIjTtyOAf5cyTIND/PqRskZJBrEjfU9nhINA/A/5kVjF4 gEwgXbJSMdiD2RPv2eHWz0XCHPpZnfLiYjjS/3fRnuE+gCASNKEgUT3hceH/PEAHkSHxhlCDIJxw rukOwP+zYUxiPGWiKcP10hI5Ga1R/9aiOvBMZElDWdAiwFTACHD/QUKeFi5whlBo8UyCR+TRov8i IOOzA6CxZUUwcsEhsiK197HXQhcc9ChNtK227Msf4f8kkDXQwAJFYFKQCGAhITkwfzvhPhThtiAS QJU6Jh7ma/1jcHdHQUy0I4+fEdyTbgH/nRRFMKU21RIDIK8HzJTqQ32fQ2NDEUBhNlH11A8QcP8N 4ONiOoFDJfkiS4EPoD4T/76x1qNH5TthFBAooPxUY3D/4fNP0VamHdFZ0WAztkIErv9X8EAW/FdN GE/DBdNoddix//sxtK7UFLaaBKRQAh+xUIX/9dRRsFwBH/IesWImFBCucf4nV8B0AD0hzjNHwBQg QVL/kkMjJFgGeABWMV/SPoCdAv+ukUjxIbJS1qoSPYDltGCC/zzSZWJy/j0S5FD7IMlRTHG/t2IF H0UwBmQf5fXUStyh/4XAB4PjtFfh9dRAEQofIMH/BsLbggaAQGFRQUPSS8EGLP+0uDgnCqnd0Q88 EHIrEEci/8wFm8Fpgooz+mgUgzfinOT9EfRy72OSkzZRNuL8+49D/ec6XyuvLL8tivXUhVM60X// 0ExiO+BZ0C6Zeoye4HTQcDovL/+yLoNaMgP5/7BuLy/SeACwoDOgfFL/Ku81nzavLh8vLzA/g8kx rxcyvzPPdjx9P8AAAB4ANRABAAAASAAAADw0MDMwMTU4MUIyOTYyQjQ0ODY5MEEwMjNFRjE2REZF MTFEODM1MUBic24tbWFpbC0wMS5ic3Rvcm1uZXR3b3Jrcy5jb20+AB4ARxABAAAADwAAAG1lc3Nh Z2UvcmZjODIyAAALAPIQAQAAAB8A8xABAAAAXgAAAFIARQAlADMAQQAgAFsATAB3AGEAcABwAF0A IABSAGUAcABsAGEAeQAgAGkAcwBzAHUAZQAgAGkAbgAgAEEALgAzACAAcgBlAGsAZQB5AGkAbgBn AC4ARQBNAEwAAAAAAAsA9hAAAAAAQAAHMJGjJx3SNcMBQAAIMHxRRlbSNcMBAwDeP+QEAAADAPE/ CQQAAB4A+D8BAAAACwAAAFJvaGl0IFN1cmkAAAIB+T8BAAAAYAAAAAAAAADcp0DIwEIQGrS5CAAr L+GCAQAAAAAAAAAvTz1CTEFDSyBTVE9STS9PVT1GSVJTVCBBRE1JTklTVFJBVElWRSBHUk9VUC9D Tj1SRUNJUElFTlRTL0NOPVJTVVJJAB4A+j8BAAAAFQAAAFN5c3RlbSBBZG1pbmlzdHJhdG9yAAAA AAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAAAwD9P+QEAAADABlA AAAAAAMAGkAAAAAAAwAdQAAAAAADAB5AAAAAAB4AMEABAAAABgAAAFJTVVJJAAAAHgAxQAEAAAAG AAAAUlNVUkkAAAAeADJAAQAAABMAAABiaGFuZGFydUBsZWdyYS5jb20AAB4AM0ABAAAAEwAAAGJo YW5kYXJ1QGxlZ3JhLmNvbQAAHgA4QAEAAAAGAAAAUlNVUkkAAAAeADlAAQAAAAIAAAAuAAAACwAp AAAAAAALACMAAAAAAAMABhA1aEdyAwAHEDwMAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAA U0VRVUVOQ0VOVU1CRVJJU0FMUkVBRFlERUZJTkVESU5USEVQUk9UT0NPTCxUSElTSVNVU0VEVE9Q UkVWRU5UVEhFUkVQTEFZQVRUQUNLU1JPSElULS0tLS1PUklHSU5BTE1FUwAAAAACAX8AAQAAAEgA AAA8NDAzMDE1ODFCMjk2MkI0NDg2OTBBMDIzRUYxNkRGRTExRDgzNTFAYnNuLW1haWwtMDEuYnN0 b3JtbmV0d29ya3MuY29tPgC2Vw== ------_=_NextPart_001_01C335D2.56418CBE-- From lwapp@frascone.com Wed Jun 18 20:49:30 2003 From: lwapp@frascone.com (Scott G. Kelly) Date: Wed, 18 Jun 2003 12:49:30 -0700 Subject: [Lwapp] Replay issue in A.3 rekeying References: <002801c335cd$7a2e7a60$7a0ba8c0@legra.com> Message-ID: <3EF0C24A.2BB72E2A@bstormnetworks.com> Comments inline... Nehru Bhandaru wrote: > > Is PFS (forward secrecy) the only issue here? If the session > keys are compromised the attacker can make an AP (or Alice) do > some undesirable operations - since the attacker can generate > any other protocol message in the current session - e.g change > a mobile key. > > It seems to me what the protocol needs is a replay protection. > The scheme of encrypting the key material with target (AP) > public key and signing by the originator (AR) should provide > the needed authentication for the exchange. However the > response from AR can be replayed - in the least causing > a denial of service. IMO a key sequence/replay counter > should be incorporated into this scheme so the receiver > can at least ignore replays. Remember, the earlier email says the exchange description in the draft is out of date, and that what actually happens is that the AP generates a nonce and sends this in the join request to the AR. The AR then generates key material, encrypts this with the PK of the AP, concatenates this with the nonce, and signs this blob. The nonce provides replay protection. If the AP generates the nonce, and the AR signs this along with the key material, then this could only be replayed if the AP generates the same nonce again. If the nonce is a 32-bit (effectively) random value, this is highly unlikely. > One a more general note, why not leverage key exchanges > imminently prevalent (:-)) or prevalent protocols such > as 802.11i key exchanges or use TLS since certificates > are used for these security schemes anyway. If we operated at layer 3, I might think of using a simplified IKE or SSL/TLS implementation. If we want to support L3 AP's (or preshared keys), then I agree that either one of these key exchanges or a new one based on one of them seems to make sense. At layer 2, I don't think there are currently any standardized key agreement/exchange protocols, though I suppose it's possible that one could adapt TLS (a la EAP-TLS) for this purpose - but we were aiming to keep this as light-weight as possible. Still, I wouldn't rule this out. Scott From lwapp@frascone.com Wed Jun 18 20:57:16 2003 From: lwapp@frascone.com (Nehru Bhandaru) Date: Wed, 18 Jun 2003 15:57:16 -0400 Subject: [Lwapp] Replay issue in A.3 rekeying In-Reply-To: <40301581B2962B448690A023EF16DFE11D8351@bsn-mail-01.bstormnetworks.com> Message-ID: <002d01c335d3$d1513e80$7a0ba8c0@legra.com> I was referring to a "key sequence" number, not the sequence number in all the lwapp control messages. For example 802.11i uses a key replay counter in the key frames. - Nehru -----Original Message----- From: Rohit Suri [mailto:lwapp-admin@frascone.com] On Behalf Of Rohit Suri Sent: Wednesday, June 18, 2003 3:47 PM To: lwapp@frascone.com Subject: RE: [Lwapp] Replay issue in A.3 rekeying Sequence Number is already defined in the protocol, This is used to prevent the replay attacks. Rohit -----Original Message----- From: Nehru Bhandaru [mailto:bhandaru@legra.com] Sent: Wed 6/18/2003 12:11 PM To: lwapp@frascone.com Cc: Subject: RE: [Lwapp] Replay issue in A.3 rekeying Is PFS (forward secrecy) the only issue here? If the session keys are compromised the attacker can make an AP (or Alice) do some undesirable operations - since the attacker can generate any other protocol message in the current session - e.g change a mobile key. It seems to me what the protocol needs is a replay protection. The scheme of encrypting the key material with target (AP) public key and signing by the originator (AR) should provide the needed authentication for the exchange. However the response from AR can be replayed - in the least causing a denial of service. IMO a key sequence/replay counter should be incorporated into this scheme so the receiver can at least ignore replays. One a more general note, why not leverage key exchanges imminently prevalent (:-)) or prevalent protocols such as 802.11i key exchanges or use TLS since certificates are used for these security schemes anyway. My two cents... - Nehru -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Scott G. Kelly Sent: Wednesday, June 18, 2003 1:16 PM To: lwapp@frascone.com Subject: Re: [Lwapp] Replay issue in A.3 rekeying Hi David, Comments below... David Molnar wrote: > > On Tue, 17 Jun 2003, Scott G. Kelly wrote: > > Thanks for your quick response! > > >>integrity of Alice's or Charlie's runtime memory, or he gets Alice or >>Charlie to somehow leak C1. This may be possible, but in such cases, >>might it not also be possible to determine the actual session keys, >>and even Alice or Charlie's private keys? > > > I agree that it's a bit far-fetched to think that this might happen in > practice. At the same time, I note that the stated rationale for > having the rekeying message consist of a session key encrypted with > the AR's public key is to provide forward secrecy: > > "[the C1 message] provides a form of > forward secrecy, as an attacker who has broken the current AR-AP > session key must also have broken the AR's private RSA key to > determine this new value." (appendix A.3, page 57) > > It looks like the draft is *already* considering a scenario in which > the current session key has been broken, yet the AR and even the AP > remain physically secure and the new session key cannot just be "read > out" by the attacker from a compromised endpoint. Otherwise there > would be no point to "forward secrecy" in the draft, since as you > point out, the adversary could just read out the new session key. Yes, you are right - the FS property does presuppose that the existing session keys have been compromised. And taking this a step further, assuming that they have, then having a way to replay the rekey message (with the same session keys in it) has obvious implications, since the attacker already knows the keys. Rohit points out in a private email that the draft does not accurately depict our current implementation, and that the AP sends the nonce and request to the AR, and that the AR generates the key material and sends it back encrypted with the APs public key, and signed by the AR. In this case, I'm wondering whether your attack can be inverted - but I need to think about this some more. My understanding is that the AP sends a nonce in the JoinRequest, the AR gens the key material, and a concatenation of the nonce and encrypted key material are signed by the AR. Seems like this prevents the inversion, but I'm working quickly here. Scott _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From lwapp@frascone.com Wed Jun 18 20:59:46 2003 From: lwapp@frascone.com (Pat R. Calhoun) Date: Wed, 18 Jun 2003 12:59:46 -0700 Subject: [Lwapp] Replay issue in A.3 rekeying Message-ID: <40301581B2962B448690A023EF16DFE157A33B@bsn-mail-01.bstormnetworks.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C335D4.2AB78C63 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable One a more general note, why not leverage key exchanges imminently prevalent (:-)) or prevalent protocols such as 802.11i key exchanges or use TLS since certificates are used for these security schemes anyway. The primary issue is that it would provide device authentication, = but there is no way to encrypt the traffic over ethernet networks. Since = our requirement is for both privacy as well as authentication over a = wired network, this proposal would not work. PatC ------_=_NextPart_001_01C335D4.2AB78C63 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+Ii8TAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAKQAAAFJFOiBbTHdhcHBdIFJlcGxh eSBpc3N1ZSBpbiBBLjMgcmVrZXlpbmcAug0BBYADAA4AAADTBwYAEgAMADsALgADAGoBASCAAwAO AAAA0wcGABIADAA7AC4AAwBqAQEJgAEAIQAAAEJENkYxMjQ1MzVCRkE3NDBBNkY4NTQwNjhGOTBB M0NGAEIHAQOQBgDgCAAANwAAAAMAJgAAAAAAAwA2AAAAAABAADkAY4y3KtQ1wwEeAD0AAQAAAAUA AABSRTogAAAAAAIBRwABAAAAOQAAAGM9dXM7YT0gO3A9QmxhY2sgU3Rvcm07bD1CU04tTUFJTC0w MS0wMzA2MTgxOTU5NDZaLTEwMTAzAAAAAB4ASQABAAAAKQAAAFJFOiBbTHdhcHBdIFJlcGxheSBp c3N1ZSBpbiBBLjMgcmVrZXlpbmcAAAAAQABOAIAiIHrNNcMBHgBaAAEAAAAPAAAATmVocnUgQmhh bmRhcnUAAAIBWwABAAAAPwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAE5laHJ1IEJoYW5kYXJ1 AFNNVFAAYmhhbmRhcnVAbGVncmEuY29tAAACAVwAAQAAABgAAABTTVRQOkJIQU5EQVJVQExFR1JB LkNPTQAeAF0AAQAAAA8AAABOZWhydSBCaGFuZGFydQAAAgFeAAEAAAA/AAAAAAAAAIErH6S+oxAZ nW4A3QEPVAIAAAAATmVocnUgQmhhbmRhcnUAU01UUABiaGFuZGFydUBsZWdyYS5jb20AAAIBXwAB AAAAGAAAAFNNVFA6QkhBTkRBUlVATEVHUkEuQ09NAB4AZgABAAAABQAAAFNNVFAAAAAAHgBnAAEA AAATAAAAYmhhbmRhcnVAbGVncmEuY29tAAAeAGgAAQAAAAUAAABTTVRQAAAAAB4AaQABAAAAEwAA AGJoYW5kYXJ1QGxlZ3JhLmNvbQAAHgBwAAEAAAAlAAAAW0x3YXBwXSBSZXBsYXkgaXNzdWUgaW4g QS4zIHJla2V5aW5nAAAAAAIBcQABAAAAGwAAAAHDNc2H/N0980QgHkTXhDilhfTtH5wAAZvVegAe AHQAAQAAABMAAABsd2FwcEBmcmFzY29uZS5jb20AAB4AGgwBAAAADwAAAFBhdCBSLiBDYWxob3Vu AAAeAB0OAQAAACUAAABbTHdhcHBdIFJlcGxheSBpc3N1ZSBpbiBBLjMgcmVrZXlpbmcAAAAAAgEJ EAEAAAAgAgAAHAIAAAsDAABMWkZ1pm95tQMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QH EwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8O MDURIgxgYwBQMwsJAWQzNhZQC6YgT2BuZSBhIARgGCAgjmcJ8ASQB0Agbm8OsCAsIHdoeR4SIGyM ZXYd0R2gIGtlHqDrDsAT0W4doHMKogqAB3CmbQuACfB0bB6gcBggBnYHQCERICg6LSm8KSAFsSF4 IXAeMG8XkVUEIHMa0GggZGEEIDjAMDIuMTFpH4wiYmJ1FBAgVEwF8ACQbr5jHRAm8AAgBpAN4GEO sM8gVQrAHRAmQWQgAhAFwFx0aAeQHRAUEGMIcXQfHqAE8CkgB4IAcHl3YQx5LiBkIGQ8UFJD/j4m cCkgIWEHcArAHqAEAb8KUCzBKQEnoCzABUB3CGCmbCiwI0F2aQEAIAEAcy5wJvFhdSkRAjAngmn7 AiAeYGIvQCkCHXEtMR4gvx5wKsApADEQCfAFAHkFMf8pESkAHeABIA3gImAfIR/AHzByHQAFQDOB LeBya3MuLgYAJtMIYSAYIHF1/mkYIAeAIeEtMSjSBuApEBssQiGgYx6gJIF3ZWz/AyAkgS88MtQd MAPwGCEzto8eYCkQLTEjQXBvcx3xry3kHsIz8irrUCegQyr6An09oB4ANRABAAAASAAAADw0MDMw MTU4MUIyOTYyQjQ0ODY5MEEwMjNFRjE2REZFMTU3QTMzQkBic24tbWFpbC0wMS5ic3Rvcm1uZXR3 b3Jrcy5jb20+AB4ARxABAAAADwAAAG1lc3NhZ2UvcmZjODIyAAALAPIQAQAAAB8A8xABAAAAXgAA AFIARQAlADMAQQAgAFsATAB3AGEAcABwAF0AIABSAGUAcABsAGEAeQAgAGkAcwBzAHUAZQAgAGkA bgAgAEEALgAzACAAcgBlAGsAZQB5AGkAbgBnAC4ARQBNAEwAAAAAAAsA9hAAAAAAQAAHMPNrTvfT NcMBQAAIMCFRvCrUNcMBAwDeP+QEAAADAPE/CQQAAB4A+D8BAAAADwAAAFBhdCBSLiBDYWxob3Vu AAACAfk/AQAAAGMAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089QkxBQ0sgU1RPUk0v T1U9RklSU1QgQURNSU5JU1RSQVRJVkUgR1JPVVAvQ049UkVDSVBJRU5UUy9DTj1QQ0FMSE9VTgAA HgD6PwEAAAAVAAAAU3lzdGVtIEFkbWluaXN0cmF0b3IAAAAAAgH7PwEAAAAeAAAAAAAAANynQMjA QhAatLkIACsv4YIBAAAAAAAAAC4AAAADAP0/5AQAAAMAGUAAAAAAAwAaQAAAAAADAB1AAAAAAAMA HkAAAAAAHgAwQAEAAAAJAAAAUENBTEhPVU4AAAAAHgAxQAEAAAAJAAAAUENBTEhPVU4AAAAAHgAy QAEAAAATAAAAYmhhbmRhcnVAbGVncmEuY29tAAAeADNAAQAAABMAAABiaGFuZGFydUBsZWdyYS5j b20AAB4AOEABAAAACQAAAFBDQUxIT1VOAAAAAB4AOUABAAAAAgAAAC4AAAALACkAAAAAAAsAIwAA AAAAAwAGEED3vNIDAAcQiAEAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABPTkVBTU9SRUdF TkVSQUxOT1RFLFdIWU5PVExFVkVSQUdFS0VZRVhDSEFOR0VTSU1NSU5FTlRMWVBSRVZBTEVOVCg6 LSkpT1JQUkVWQUxFTlRQUk9UT0NPTFNTVUNIQVM4MDIxAAAAAAIBfwABAAAASAAAADw0MDMwMTU4 MUIyOTYyQjQ0ODY5MEEwMjNFRjE2REZFMTU3QTMzQkBic24tbWFpbC0wMS5ic3Rvcm1uZXR3b3Jr cy5jb20+AGsR ------_=_NextPart_001_01C335D4.2AB78C63-- From lwapp@frascone.com Wed Jun 18 21:48:06 2003 From: lwapp@frascone.com (Rohit Suri) Date: Wed, 18 Jun 2003 13:48:06 -0700 Subject: [Lwapp] Replay issue in A.3 rekeying Message-ID: <40301581B2962B448690A023EF16DFE11D8352@bsn-mail-01.bstormnetworks.com> This is a multi-part message in MIME format. ------_=_NextPart_001_01C335DA.EB3B846B Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As responded by Scott , sessionId is used for that. Rohit -----Original Message----- From: Nehru Bhandaru [mailto:bhandaru@legra.com] Sent: Wed 6/18/2003 12:57 PM To: lwapp@frascone.com Cc:=09 Subject: RE: [Lwapp] Replay issue in A.3 rekeying I was referring to a "key sequence" number, not the sequence number in all the lwapp control messages. For example 802.11i uses a key replay counter in the key frames. - Nehru -----Original Message----- From: Rohit Suri [mailto:lwapp-admin@frascone.com] On Behalf Of=20 Rohit Suri Sent: Wednesday, June 18, 2003 3:47 PM To: lwapp@frascone.com Subject: RE: [Lwapp] Replay issue in A.3 rekeying Sequence Number is already defined in the protocol, This is=20 used to prevent the replay attacks. Rohit -----Original Message----- From: Nehru Bhandaru [mailto:bhandaru@legra.com] Sent: Wed 6/18/2003 12:11 PM To: lwapp@frascone.com Cc:=09 Subject: RE: [Lwapp] Replay issue in A.3 rekeying Is PFS (forward secrecy) the only issue here? If the session=20 keys are compromised the attacker can make an AP (or Alice) do=20 some undesirable operations - since the attacker can generate=20 any other protocol message in the current session - e.g change=20 a mobile key.=20 It seems to me what the protocol needs is a replay protection.=20 The scheme of encrypting the key material with target (AP)=20 public key and signing by the originator (AR) should provide=20 the needed authentication for the exchange. However the=20 response from AR can be replayed - in the least causing a=20 denial of service. IMO a key sequence/replay counter=20 should be incorporated into this scheme so the receiver=20 can at least ignore replays. One a more general note, why not leverage key exchanges=20 imminently prevalent (:-)) or prevalent protocols such as=20 802.11i key exchanges or use TLS since certificates are used=20 for these security schemes anyway. My two cents... - Nehru=20 -----Original Message----- From: lwapp-admin@frascone.com=20 [mailto:lwapp-admin@frascone.com] On Behalf Of Scott G. Kelly Sent: Wednesday, June 18, 2003 1:16 PM To: lwapp@frascone.com Subject: Re: [Lwapp] Replay issue in A.3 rekeying Hi David, Comments below... David Molnar wrote: >=20 > On Tue, 17 Jun 2003, Scott G. Kelly wrote: >=20 > Thanks for your quick response! >=20 >=20 >>integrity of Alice's or Charlie's runtime memory, or he gets Alice or >>Charlie to somehow leak C1. This may be possible, but in such cases,=20 >>might it not also be possible to determine the actual session keys,=20 >>and even Alice or Charlie's private keys? >=20 >=20 > I agree that it's a bit far-fetched to think that this might happen in=20 > practice. At the same time, I note that the stated rationale for > having the rekeying message consist of a session key encrypted with=20 > the AR's public key is to provide forward secrecy: >=20 > "[the C1 message] provides a form of > forward secrecy, as an attacker who has broken the current AR-AP > session key must also have broken the AR's private RSA key to > determine this new value." (appendix A.3, page 57) >=20 > It looks like the draft is *already* considering a scenario in which > the current session key has been broken, yet the AR and even the AP=20 > remain physically secure and the new session key cannot just be "read=20 > out" by the attacker from a compromised endpoint. Otherwise there=20 > would be no point to "forward secrecy" in the draft, since as you=20 > point out, the adversary could just read out the new session key. Yes, you are right - the FS property does presuppose that the existing=20 session keys have been compromised. And taking this a step further,=20 assuming that they have, then having a way to replay the rekey message=20 (with the same session keys in it) has obvious implications, since the=20 attacker already knows the keys. Rohit points out in a private email that the draft does not accurately=20 depict our current implementation, and that the AP sends the nonce and=20 request to the AR, and that the AR generates the key material and sends=20 it back encrypted with the APs public key, and signed by the=20 AR. In this=20 case, I'm wondering whether your attack can be inverted - but I need to=20 think about this some more. My understanding is that the AP sends a nonce in the=20 JoinRequest, the AR=20 gens the key material, and a concatenation of the nonce and encrypted=20 key material are signed by the AR. Seems like this prevents the=20 inversion, but I'm working quickly here. Scott _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp ------_=_NextPart_001_01C335DA.EB3B846B Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgcUAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEAKQAAAFJFOiBbTHdhcHBdIFJlcGxh eSBpc3N1ZSBpbiBBLjMgcmVrZXlpbmcAug0BBYADAA4AAADTBwYAEgANADAABgADADgBASCAAwAO AAAA0wcGABIADQAwAAYAAwA4AQEJgAEAIQAAADY1RUJCMjYzODM0OTRENEU4NTgxQUI2NTI2QzZF NjRFADEHAQOQBgBsEQAANwAAAAMAJgAAAAAAAwA2AAAAAABAADkAa4Q769o1wwEeAD0AAQAAAAUA AABSRTogAAAAAAIBRwABAAAAOQAAAGM9dXM7YT0gO3A9QmxhY2sgU3Rvcm07bD1CU04tTUFJTC0w MS0wMzA2MTgyMDQ4MDZaLTEwMTQ2AAAAAB4ASQABAAAAKQAAAFJFOiBbTHdhcHBdIFJlcGxheSBp c3N1ZSBpbiBBLjMgcmVrZXlpbmcAAAAAQABOAAD2KNHTNcMBHgBaAAEAAAAPAAAATmVocnUgQmhh bmRhcnUAAAIBWwABAAAAPwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAE5laHJ1IEJoYW5kYXJ1 AFNNVFAAYmhhbmRhcnVAbGVncmEuY29tAAACAVwAAQAAABgAAABTTVRQOkJIQU5EQVJVQExFR1JB LkNPTQAeAF0AAQAAAA8AAABOZWhydSBCaGFuZGFydQAAAgFeAAEAAAA/AAAAAAAAAIErH6S+oxAZ nW4A3QEPVAIAAAAATmVocnUgQmhhbmRhcnUAU01UUABiaGFuZGFydUBsZWdyYS5jb20AAAIBXwAB AAAAGAAAAFNNVFA6QkhBTkRBUlVATEVHUkEuQ09NAB4AZgABAAAABQAAAFNNVFAAAAAAHgBnAAEA AAATAAAAYmhhbmRhcnVAbGVncmEuY29tAAAeAGgAAQAAAAUAAABTTVRQAAAAAB4AaQABAAAAEwAA AGJoYW5kYXJ1QGxlZ3JhLmNvbQAAHgBwAAEAAAAlAAAAW0x3YXBwXSBSZXBsYXkgaXNzdWUgaW4g QS4zIHJla2V5aW5nAAAAAAIBcQABAAAAGwAAAAHDNdP4QWTUeHbubkmit/Tjh2NgGSoAAa+llgAe AHQAAQAAABMAAABsd2FwcEBmcmFzY29uZS5jb20AAB4AGgwBAAAACwAAAFJvaGl0IFN1cmkAAB4A HQ4BAAAAJQAAAFtMd2FwcF0gUmVwbGF5IGlzc3VlIGluIEEuMyByZWtleWluZwAAAAACAQkQAQAA AMEKAAC9CgAA+BYAAExaRnWcoAYkAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP 8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAGwxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREi DGBjAFDzCwkBZDM2FlALpgrjCoBmQQQgGCBzcAIgAQBkOCBieQYABaACQCAs1iAUEAQQaQIgSR4A BAC8IHUUEB4AAhAFwHQT4Bx0Lhz0HPQIAGhpdNUgii0iUk8FEGcLgAdAYwXQHuFhZ2UiUxz0Rg0D YToMggexaHJ1IN5CE+Ad0ArAJTBbAMADEBB0bzpiJWVAbGXJCcBhLgWgbV0c9AZgCwIwJJRXHfE2 LzE4Ii8B0DAzIA4gOjXQNyBQTRz0VCZAJKNAbHdhcHBAA1BhmwTwAiBlJ0Ic9ENjJJQxJ5V1YmoF kCglUkWqOiXQTCriXQfwZQtRnx4wBAEKUB9gA6BBLilQURgga2V5C4BnIIpJ9iAq4B1iZgSQBRAw YCAgYG8gYSAiMCEewXEBClBuY2UiIG519wbQBJAesG4ecCAhL3Ay5n8c9DOEL4IHQAMgNEIq0yA9 K3F0A2ADIAeBI2JzLswgRgWxDsBhbQtQL3CAODAyLjExaR+SfnMc9DJwMqIYIC7jBaB1fwIwNaQ0 QjKiKzEHgSB7Lf8k5CGfIq8jvQfxIWEGAAhxwyXXKtMtYWRtC4ArK7UuoE8DoEIlAAdAZkNgv0Pw IOlA8yeZKIIrkHMlkPp5HrBKOtAvcCjwHrApI/gzOjQpuyrPK9YtNi3//y8PMB9NfyfDMwQHsDV1 BCD/B0AYIEIwHjABAQuAHfE7Nd5wA2AmMBeRHrBUIWAEIJ8fcRz0H6MyQVGwZXYoAc80MzpFIFAB kGNrPDwhT/8+Tz9fJH8ljyafJ68ovTkA/ynPSK8r7yz/Sr9Lz0zfMTDpBCBQRgXwKB/xX8ALIGce wQUABZB5KTQzAiBsx2P2NFAYID8gSUPwNET/HvMc5WUBUCEYIDbROHADYd8EAFNSNFFU5BKBYwOR AMA3ZQAyYGSBUGaABbFBbLUN4GVnkGQyUBz0cwNwf2RQOtABAACQXAACYGfRcP8EkCBQHxEEID0Q AJBPYmuv31hgYHBv4WRQOYVuHjAecO9ooVGnN1Y7JmMIcBggVAH/aXY9EGCAMiAT0TBgcmc3UHxv YgMQO4M34DCLdWJl7m0EIDJBbsF3IEFRazNw/QngZFKDMnA6RVGyYlEfEf939lJQNGET0HkgZ9FD 8DMh/HJ5BTAyAzt1AMA68QcxezFQVlBoICAKwFhgBUAo920wZ5Ac9HBiIG2xOfNaUf1wcWcDADIR HiFns1eUWxBLBcCAgFJnkHNoCGBs8x4AUbF2aQEAHOU0Qnri+R3xYXU0QQIwDeBv8x/lj2RQDsB2 ZDfgSG93U9F/hyQc9B2EFBA70QNwEMBS/2xjM7A6NR3xPRA7NVvQYDD/BUBscB+gMgIycBz0AQAD AHdX4X3RFBByhLAzQDfgSexNTzJhMqovOk1uRYQk/4qRcJEFsB2wcjJRIjJBIDDfH3F9ZW6gVCUz QGmIYhz0/2xyeeGL5IIxBbBUVjw8Q3D/a8F3QWqxcfR6wXwhHrB5wP8eMDQCW9CIYXRSMqKHhlK2 fwdwQlFc4WgRU7IHQFPyKPg6LSlnkAWxm+hRtpLh/xrQf/AxcRz0OMaZ/AWxH6H9UkBMBfBwhDNA ACAGkIaC/weRaqIfoxz0hwWJoWchCHH+dDLBfXNQIXLwX8B34FVq+k2CsXcyUDNAAjA30KcA/zxf WgFN/1bPV98/+UHfYGVfHOVBX0JvQ3seVEc34Et6ZTYQeUVPRl8pQl5wNvdH31//SftlYw9kH0z/ HQPSSDkgRGGEsSxVaghQ75tApsKKgRewd6cNu1MF0HcG8KqQBcB3fBJZcB0DPrcc5b/QQ3FUClAe sDEpsP9GsUczHrCxPL8Pv5RSUABwa1UwH+N5CGEgMwAN4GvbHXUUECG/fr91PpJhW+HXpFJ90W2j J6BzQxPhbbD/yJJaAIZhbsEHgJexs1EFsf80UYBBELFtsoMBxwbJBTIyn26ihCAH4IvhxVBDMTfg /1JTAMAeMIqRHbAe8W9xHrD+YoYguQKeU2xwHtEesMcG+a9AZ2iVgQVANAIHQJNxf86pMjIBADrx m1Jw1GJgdf+qoWl2alLQiIHiU9LLR8j571GwlCByQmpSP8YPv4UxQP+rEAnRICPRccihMnB3cAVA 6mYKwC0xwHR9cVNjkrH/xEDaZJKz0SMc9BPgtaDWQd+5Eb92UbDUEY4jQTQlPAH/ICAHcR6wMUCY gty2NGEBkP+SIm/knCEf4r92E+CEsH6F/7mGdAdgUQCQjBF90TJw1In/ffYd8X/Dv3Y0QoPQ13KB SD8fcVODhKRmrcMP7IQiW/80Qs3QN1a4IISFe1If8YoA/33Q7BxmrR6wMXGU42wFecB/MlAT4Lzh A2C5oHSsg9At920w7BzmSm0foNHV47G48Mfymei017VSU0E581sQf+wc0zofcWBwB+CcEQpQLsUz YCjeI2RpeLkyHrC3CrB0YSmgKdj/lSFv8rDvBCBtsGzRNEJkXAABgB9i+ipQRSrlZASBjIQE8Anw 3wrAHxC5AnnADeBo5/p1Dv8yovJTCeHyhR6wixA0JIohf9Xn6HNtQL92GCBa0d6QcP+Y8A3RNgEy wnUBbOJrhPqSt+ZKlNE0Amr1woqRIlBi+7/nEkB0M2CCpWvnidMycN9q6vuRHbCSYTfgT3My56D/ iaFzMnJmv9CmgJElNADOwfuSYTIyImatM2A7Nf7jHrH/cJMxccTB3qgRkwwhHrBw4/5kiGGrAH4w OqKEUQrDC1PvDCEJD3fCVWpZ0GIUomqi/6pR0VE9EDRCZmFRsW/Bx/H/bhCaoVOxuNC1oM7g4Uk4 QP/lsTICbkXUmfZFBFJq6d+x/wjizaB+dHtDjBC4UIbwpDD/czLQhmAwuNCvQX6SeeQD4v9T4BXz 3pDjtTJwpUEyMjpF9+QndAenlCh/xOAWHwu5Ef9WUGeQBAJ3YISwDCBSgThxv4aF0HFwiDmFa/ZQ Rms0AP53eUE7dFVPQNEO06Bxz4T/MnDXpgdSNiJ55f7kHIPRs95jdQH34WgRjOZwbcAVov9xkXUV K2J9kVzwb/PxAQjj/3nlbTFrYG8ALpThEBQzgfH/iOaPMYwRkoPokjbuijBx9v8ul38ogeM4E5rV CvFxUeb+/wZU6Oo25IIiDnEMdaeUg9DfjlGLglKn0DLg0SeKAKaA/28BAIN5wNvAc0LEw1Tkikb/ qoCIYZIidgDPcuDxevHS8v+FBtyCb2AX9JLSbrKXsqV+/27yFpBxQPuhfoHpsjdfjrD3OKSLdaeU Sg7huEA5wxX074ohp5Rx8TxfbDbkDcKPYP/34YNhabLIIThs5whp9zzp/wihQXxCslzQeSL+Vc4x m+K/vLOIqEbDaaLPVEQ0ciGjv8UTaBFooi87wcMvSl9d7/9e/1/Kp5S302yhd4B+coFgD4wQYNmt DBswdHA6LzovrlIutdpkQ65Qbi//YhKqgIcAZeCu0l0vZ99o7/9gX2FvYn9jj2SfZa9mvGbf/3JP c19qD2sfbC+2SW2fbq8Lb79wzH18cAAAAB4ANRABAAAASAAAADw0MDMwMTU4MUIyOTYyQjQ0ODY5 MEEwMjNFRjE2REZFMTFEODM1MkBic24tbWFpbC0wMS5ic3Rvcm1uZXR3b3Jrcy5jb20+AB4ARxAB AAAADwAAAG1lc3NhZ2UvcmZjODIyAAALAPIQAQAAAB8A8xABAAAAXgAAAFIARQAlADMAQQAgAFsA TAB3AGEAcABwAF0AIABSAGUAcABsAGEAeQAgAGkAcwBzAHUAZQAgAGkAbgAgAEEALgAzACAAcgBl AGsAZQB5AGkAbgBnAC4ARQBNAEwAAAAAAAsA9hAAAAAAQAAHMEZG07baNcMBQAAIMKXSSevaNcMB AwDeP+QEAAADAPE/CQQAAB4A+D8BAAAACwAAAFJvaGl0IFN1cmkAAAIB+T8BAAAAYAAAAAAAAADc p0DIwEIQGrS5CAArL+GCAQAAAAAAAAAvTz1CTEFDSyBTVE9STS9PVT1GSVJTVCBBRE1JTklTVFJB VElWRSBHUk9VUC9DTj1SRUNJUElFTlRTL0NOPVJTVVJJAB4A+j8BAAAAFQAAAFN5c3RlbSBBZG1p bmlzdHJhdG9yAAAAAAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAA AwD9P+QEAAADABlAAAAAAAMAGkAAAAAAAwAdQAAAAAADAB5AAAAAAB4AMEABAAAABgAAAFJTVVJJ AAAAHgAxQAEAAAAGAAAAUlNVUkkAAAAeADJAAQAAABMAAABiaGFuZGFydUBsZWdyYS5jb20AAB4A M0ABAAAAEwAAAGJoYW5kYXJ1QGxlZ3JhLmNvbQAAHgA4QAEAAAAGAAAAUlNVUkkAAAAeADlAAQAA AAIAAAAuAAAACwApAAAAAAALACMAAAAAAAMABhBXhEk9AwAHEJEOAAADABAQAAAAAAMAERAAAAAA HgAIEAEAAABlAAAAQVNSRVNQT05ERURCWVNDT1RULFNFU1NJT05JRElTVVNFREZPUlRIQVRST0hJ VC0tLS0tT1JJR0lOQUxNRVNTQUdFLS0tLS1GUk9NOk5FSFJVQkhBTkRBUlVNQUlMVE86QkhBTgAA AAACAX8AAQAAAEgAAAA8NDAzMDE1ODFCMjk2MkI0NDg2OTBBMDIzRUYxNkRGRTExRDgzNTJAYnNu LW1haWwtMDEuYnN0b3JtbmV0d29ya3MuY29tPgBY7A== ------_=_NextPart_001_01C335DA.EB3B846B-- From lwapp@frascone.com Wed Jun 18 22:23:50 2003 From: lwapp@frascone.com (David Molnar) Date: Wed, 18 Jun 2003 17:23:50 -0400 (EDT) Subject: [Lwapp] Replay issue in A.3 rekeying In-Reply-To: <3EF0C24A.2BB72E2A@bstormnetworks.com> References: <002801c335cd$7a2e7a60$7a0ba8c0@legra.com> <3EF0C24A.2BB72E2A@bstormnetworks.com> Message-ID: On Wed, 18 Jun 2003, Scott G. Kelly wrote: > SSL/TLS implementation. If we want to support L3 AP's (or preshared > keys), then I agree that either one of these key exchanges or a new one > based on one of them seems to make sense. At layer 2, I don't think I would agree with this as well. Both SSL/TLS and IKE have been looked at by many more people than we could hope to have look at any LWAPP-specific protocol. Plus several implementations and libraries exist. > there are currently any standardized key agreement/exchange protocols, > though I suppose it's possible that one could adapt TLS (a la EAP-TLS) > for this purpose - but we were aiming to keep this as light-weight as > possible. Still, I wouldn't rule this out. OK, then let's compare the weight of TLS a la EAP-TLS and the current LWAPP keying protocol (as in draft and as amended by the recent e-mails). Maybe we can figure out the "price of TLS" and go from there. I'm actually in the middle of doing this, will e-mail the list when done. -David From lwapp@frascone.com Wed Jun 18 22:32:25 2003 From: lwapp@frascone.com (Nehru Bhandaru) Date: Wed, 18 Jun 2003 17:32:25 -0400 Subject: [Lwapp] Replay issue in A.3 rekeying In-Reply-To: <3EF0C24A.2BB72E2A@bstormnetworks.com> Message-ID: <003801c335e1$1c2f4700$7a0ba8c0@legra.com> Okay I see that the AP is protected against replays because of the Nonce. I might be missing something here, but here is some of my reasoning. Following is my understanding of the key exchange operations AP->AR: Encrypt(SessionKey, Nonce) AR->AP: Sign(kpriv-AR, Encrypt(kpub-AP, NewSessionKey)|Nonce) If the session key is compromised an attacker can impersonate the AP and send a gratuitous key update request AP(Attacker)->AR: Encrypt(SessionKey,Nonce2) AR->AP: Sign(kpriv-AR, Encrypt(kpub-AP, NewSessionKey2)|Nonce2) At this point does the AR update its session key? If so, it would break the current session between AP and AR. Alternatively the attacker can replay the original AP->AR message. The sequence number of the control packet would provide some protection against this if the session keys were not compromised, but there are probably ways around this because it is only 8 bits. In this case the AR would generate another session key and generate the response to the AP which would discard it because it does not have a matching request/nonce. However, the session is once again broken. A simple key sequence/replay counter would thwart this type of attack. This is initialized to 0 on a join and incremented each time a new key is needed by the AP. This counter can be passed as part of the request; duplicate requests can then be dropped by the AR. Perhaps one can mitigate this by signing the initial AP->AR request using kpriv-AP. It is not clear if encryption of the request using session key is buying anything in this case (for PFS). Also Nonces are ususally longer than 32 bits in cryptographic procotols; I would suggest allocating more bits to the Nonces. I am not sure if there is any reason for session id to double as the nonce in this case - session id can be 32 bits while a Nonce can be, say, 64. - Nehru -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Scott G. Kelly Sent: Wednesday, June 18, 2003 3:50 PM To: lwapp@frascone.com Subject: Re: [Lwapp] Replay issue in A.3 rekeying Comments inline... Nehru Bhandaru wrote: > > Is PFS (forward secrecy) the only issue here? If the session keys are > compromised the attacker can make an AP (or Alice) do some undesirable > operations - since the attacker can generate any other protocol > message in the current session - e.g change a mobile key. > > It seems to me what the protocol needs is a replay protection. The > scheme of encrypting the key material with target (AP) public key and > signing by the originator (AR) should provide the needed > authentication for the exchange. However the response from AR can be > replayed - in the least causing a denial of service. IMO a key > sequence/replay counter should be incorporated into this scheme so the > receiver can at least ignore replays. Remember, the earlier email says the exchange description in the draft is out of date, and that what actually happens is that the AP generates a nonce and sends this in the join request to the AR. The AR then generates key material, encrypts this with the PK of the AP, concatenates this with the nonce, and signs this blob. The nonce provides replay protection. If the AP generates the nonce, and the AR signs this along with the key material, then this could only be replayed if the AP generates the same nonce again. If the nonce is a 32-bit (effectively) random value, this is highly unlikely. > One a more general note, why not leverage key exchanges imminently > prevalent (:-)) or prevalent protocols such as 802.11i key exchanges > or use TLS since certificates are used for these security schemes > anyway. If we operated at layer 3, I might think of using a simplified IKE or SSL/TLS implementation. If we want to support L3 AP's (or preshared keys), then I agree that either one of these key exchanges or a new one based on one of them seems to make sense. At layer 2, I don't think there are currently any standardized key agreement/exchange protocols, though I suppose it's possible that one could adapt TLS (a la EAP-TLS) for this purpose - but we were aiming to keep this as light-weight as possible. Still, I wouldn't rule this out. Scott _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From pcalhoun@airespace.com Thu Jun 19 00:39:53 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Wed, 18 Jun 2003 16:39:53 -0700 Subject: [Lwapp] LWAPP L3 - one more time Message-ID: <40301581B2962B448690A023EF16DFE157A350@bsn-mail-01.bstormnetworks.com> Given that subscription has just exploded on this list, I'm going to = resend this question for those that were not on the list when I = originall sent it. I attempted to capture some Layer 3 (UDP) transport for LWAPP in the -02 draft. However, one thing that eludes me is how to do the WLAN switch discovery at Layer 3. Here are some thoughts that I've come up with, and would solicit input: 1. Multicast. The use of multicast to discovery WLAN switches across subnets seems very reasonable, except that all IT managers I've talked to disable multicast in their networks. 2. DHCP. It is possible to return a vendor specific DHCP extension. One=20 issue I've heard from a couple of sources is that in some instances DHCP servers are under the administration of another group from those responsible for WLAN service, and therefore this cannot be the only way. 3. DNS. Another mechanism, but this one does not necessarily provide geographical information, and therefore it could cause APs to associate with WLAN switches that are very far away. Not ideal. 4. Static Config. Certainly a viable method, but not very scalable. 5. SLP. Not much demand for SLP, and it suffers from many of the issues above. Thoughts? PatC From idrori@legra.com Thu Jun 19 12:33:59 2003 From: idrori@legra.com (Israel Drori) Date: Thu, 19 Jun 2003 07:33:59 -0400 Subject: [Lwapp] I welcome myself to this mailing list Message-ID: <001201c33656$ad0f8a30$6501a8c0@legra.com> __________________________ Israel Drori CEO and Founder Email: idrori@legra.com Mobile: 1-617-817-1888 Phone: 1-781-272-8400 x201 Legra Systems, Inc. 3 Burlington Woods Drive Burlington MA 01803 From M.Z.Cheng@mdx.ac.uk Thu Jun 19 13:19:55 2003 From: M.Z.Cheng@mdx.ac.uk (Michael Cheng) Date: Thu, 19 Jun 2003 13:19:55 +0100 Subject: [Lwapp] Replay issue in A.3 rekeying Message-ID: <0197940BD99CD311930D0008C75D8DD102654BCD@mdx-bg-csex.cs.mdx.ac.uk> The sequence/replay counter is one option, but signing the initial AP->AR request can't help resovle the problem. As it is one round protocol(at least I didn't related description for the 3rd message), the attacker can just replay the whole message with signature. As AP doesn't respond AR's response, AR still changes the session context without AP's complain. In fact, the attacker can lanch any join procedure if he got one old copy to change the session context in current protocol. What's more I didn't see AR verify AP's cert. Does the step really not exist in the protocol? Michael Cheng -----Original Message----- From: Nehru Bhandaru [mailto:bhandaru@legra.com] Sent: 18 June 2003 21:32 To: lwapp@frascone.com Subject: RE: [Lwapp] Replay issue in A.3 rekeying Okay I see that the AP is protected against replays because of the Nonce. I might be missing something here, but here is some of my reasoning. Following is my understanding of the key exchange operations AP->AR: Encrypt(SessionKey, Nonce) AR->AP: Sign(kpriv-AR, Encrypt(kpub-AP, NewSessionKey)|Nonce) If the session key is compromised an attacker can impersonate the AP and send a gratuitous key update request AP(Attacker)->AR: Encrypt(SessionKey,Nonce2) AR->AP: Sign(kpriv-AR, Encrypt(kpub-AP, NewSessionKey2)|Nonce2) At this point does the AR update its session key? If so, it would break the current session between AP and AR. Alternatively the attacker can replay the original AP->AR message. The sequence number of the control packet would provide some protection against this if the session keys were not compromised, but there are probably ways around this because it is only 8 bits. In this case the AR would generate another session key and generate the response to the AP which would discard it because it does not have a matching request/nonce. However, the session is once again broken. A simple key sequence/replay counter would thwart this type of attack. This is initialized to 0 on a join and incremented each time a new key is needed by the AP. This counter can be passed as part of the request; duplicate requests can then be dropped by the AR. Perhaps one can mitigate this by signing the initial AP->AR request using kpriv-AP. It is not clear if encryption of the request using session key is buying anything in this case (for PFS). Also Nonces are ususally longer than 32 bits in cryptographic procotols; I would suggest allocating more bits to the Nonces. I am not sure if there is any reason for session id to double as the nonce in this case - session id can be 32 bits while a Nonce can be, say, 64. - Nehru -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Scott G. Kelly Sent: Wednesday, June 18, 2003 3:50 PM To: lwapp@frascone.com Subject: Re: [Lwapp] Replay issue in A.3 rekeying Comments inline... Nehru Bhandaru wrote: > > Is PFS (forward secrecy) the only issue here? If the session keys are > compromised the attacker can make an AP (or Alice) do some undesirable > operations - since the attacker can generate any other protocol > message in the current session - e.g change a mobile key. > > It seems to me what the protocol needs is a replay protection. The > scheme of encrypting the key material with target (AP) public key and > signing by the originator (AR) should provide the needed > authentication for the exchange. However the response from AR can be > replayed - in the least causing a denial of service. IMO a key > sequence/replay counter should be incorporated into this scheme so the > receiver can at least ignore replays. Remember, the earlier email says the exchange description in the draft is out of date, and that what actually happens is that the AP generates a nonce and sends this in the join request to the AR. The AR then generates key material, encrypts this with the PK of the AP, concatenates this with the nonce, and signs this blob. The nonce provides replay protection. If the AP generates the nonce, and the AR signs this along with the key material, then this could only be replayed if the AP generates the same nonce again. If the nonce is a 32-bit (effectively) random value, this is highly unlikely. > One a more general note, why not leverage key exchanges imminently > prevalent (:-)) or prevalent protocols such as 802.11i key exchanges > or use TLS since certificates are used for these security schemes > anyway. If we operated at layer 3, I might think of using a simplified IKE or SSL/TLS implementation. If we want to support L3 AP's (or preshared keys), then I agree that either one of these key exchanges or a new one based on one of them seems to make sense. At layer 2, I don't think there are currently any standardized key agreement/exchange protocols, though I suppose it's possible that one could adapt TLS (a la EAP-TLS) for this purpose - but we were aiming to keep this as light-weight as possible. Still, I wouldn't rule this out. Scott _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From dmolnar@eecs.harvard.edu Thu Jun 19 17:06:44 2003 From: dmolnar@eecs.harvard.edu (David Molnar) Date: Thu, 19 Jun 2003 12:06:44 -0400 (EDT) Subject: [Lwapp] key setup - current draft v. TLS Message-ID: Hi, Here's a performance comparison of the key setup stage in the current draft with the setup in TLS. I'm going to consider plain TLS right now as in Rescorla's book _SSL and TLS_ - from looking at the EAP-TLS spec, it doesn't look like they make any major changes to the handshake. I will go through the diagrams for both protocols, then give a summary of the required operations in each case. In the current LWAPP draft, the key setup looks like AP -----------------------> AR JOIN(APCert, SessionID) AP <----------------------- AR (ARCert, C1, S1, SessionID) where C1 consists of the AR's session key encrypted with the AP's public key, and S1 is the signature of C1 concatenated with the sessionID. Total cost: 1 roundtrip, 1 encryption for AR, 1 signature for AR, 1 decryption for AP, 1 signature verification for AP, plus overhead for assembling messages, checking sessionID. In TLS mutual authentication, it looks like AP -----------------------> AR ClientHello, Ciphersuites AP <----------------------- AR ServerHello, SessionID, Ciphersuites, Certificate, CertificateRequest, ServerHelloDone AP -----------------------> AR Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec, HandshakeFinished AP <----------------------- AR ChangeCipherSpec, HandshakeFinished I won't go through all the messages, but the really important ones are ClientKeyExchange, which consists of the keying material encrypted with the AR's public key, and the CertificateVerify, which consists of a MAC of the handshake messages signed by the AP's private key. Total cost: 2 roundtrips, 1 decryption by AR, 1 signature verification by AR, 1 encryption by AP, 1 signature by AP, plus overhead for assembling messages, checking MAC, checking sessionID. Does this look correct, given other peoples' understanding of the LWAPP draft and TLS? As to how they compare, it's worth noting that we can pick a public-key algorithm, such as RSA with e=3, where encryption and signature verification is relatively fast. Usually in these cases decryption and signature generation are the "heavyweight" operations. Both TLS and the LWAPP draft have one such heavyweight operation for the AP - TLS makes the AP sign something, while LWAPP has the AP decrypt S1. Similarly, both have one heavyweight operation on the AR side - TLS has a decryption by the AR, while the current draft has a signature generation by the AR. So what do people think about the relative costs of these two protocols? -David From michaelv@legra.com Fri Jun 20 00:49:22 2003 From: michaelv@legra.com (Michael Vakulenko) Date: Thu, 19 Jun 2003 19:49:22 -0400 Subject: [Lwapp] Layer 3 LWAPP In-Reply-To: <00e201c334fa$d91c8860$b90ba8c0@student.harvard.edu> Message-ID: <5.2.0.9.0.20030619185445.03859450@in.legra.com> --=====================_350563373==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:06:58 -0700 17 Jun 2003, Pat R. Calhoun wrote: >All, > >I attempted to capture some Layer 3 (UDP) transport for LWAPP in the -02 >draft. However, one thing that eludes me is how to do the WLAN switch >discovery at Layer 3. Here are some thoughts that I've come up with, and >would solicit input: > >1. Multicast. The use of multicast to discovery WLAN switches across >subnets seems very reasonable, except that all IT managers I've talked to >disable multicast in their networks. >2. DHCP. It is possible to return a vendor specific DHCP extension. One >issue I've heard from a couple of sources is that in some instances DHCP >servers are under the administration of another group from those responsible >for WLAN service, and therefore this cannot be the only way. >3. DNS. Another mechanism, but this one does not necessarily provide >geographical information, and therefore it could cause APs to associate with >WLAN switches that are very far away. Not ideal. >4. Static Config. Certainly a viable method, but not very scalable. >5. SLP. Not much demand for SLP, and it suffers from many of the issues >above. > >Thoughts? Looking on the list above, there is no single method that works well for all possible network configurations and AP connection scenarios. Furthermore, the whole issue of AR discovery really comes down to the question how AP obtains the IP address of the AR. The method of obtaining the address has nothing to do yet with communication between the AP and AR (which is the subject of the spec). As such, discovery method does not necessary have to be defined in the LWAPP spec. It's should be up to AP implementation to pick one method or another. The spec may recommend e.g., DHCP/DNS methods. The method by itself doesn't really affect the inter-operability of AR and AP. (Same way as e.g., FTP doesn't define how client gets the IP address of the server.) The LWAPP spec by itself should only define two types of messages that will facilitate the discovery process. 1. Discovery Request message, to which AR shall respond regardless of whether it was sent using broadcast or unicast destination address. 2. Redirection Message, upon reception of which AP shall attempt to connect to the AR pointed by the Redirection Message. This approach will leave enough flexibility for implementations, while keeping the spec simple. Comments? -- Michael V. >PatC >_______________________________________________ >Lwapp mailing list >Lwapp@frascone.com >http://mail.frascone.com/mailman/listinfo/lwapp --=====================_350563373==.ALT Content-Type: text/html; charset="us-ascii" At 10:06:58 -0700 17 Jun 2003, Pat R. Calhoun wrote:
All,

I attempted to capture some Layer 3 (UDP) transport for LWAPP in the -02
draft. However, one thing that eludes me is how to do the WLAN switch
discovery at Layer 3. Here are some thoughts that I've come up with, and
would solicit input:

1. Multicast. The use of multicast to discovery WLAN switches across
subnets seems very reasonable, except that all IT managers I've talked to
disable multicast in their networks.
2. DHCP. It is possible to return a vendor specific DHCP extension. One
issue I've heard from a couple of sources is that in some instances DHCP
servers are under the administration of another group from those responsible
for WLAN service, and therefore this cannot be the only way.
3. DNS. Another mechanism, but this one does not necessarily provide
geographical information, and therefore it could cause APs to associate with
WLAN switches that are very far away. Not ideal.
4. Static Config. Certainly a viable method, but not very scalable.
5. SLP. Not much demand for SLP, and it suffers from many of the issues
above.

Thoughts?

Looking on the list above, there is no single method that works well for all possible network configurations and AP connection scenarios.

Furthermore, the whole issue of AR discovery really comes down to the question how AP obtains the IP address of the AR. The method of obtaining the address has nothing to do yet with communication between the AP and AR (which is the subject of the spec). As such, discovery method does not necessary have to be defined in the LWAPP spec.

It's should be up to AP implementation to pick one method or another. The spec may recommend e.g., DHCP/DNS methods. The method by itself doesn't really affect the inter-operability of AR and AP. (Same way as e.g., FTP doesn't define how client gets the IP address of the server.)  

The LWAPP spec by itself should only define two types of messages that will facilitate the discovery process.

1. Discovery Request message, to which AR shall respond regardless of whether it was sent using broadcast or unicast destination address.

2. Redirection Message, upon reception of which AP shall attempt to connect to the AR pointed by the Redirection Message.

This approach will leave enough flexibility for implementations, while keeping the spec simple.

Comments?

-- Michael V.


PatC
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp
--=====================_350563373==.ALT-- From scott@airespace.com Wed Jun 25 17:44:25 2003 From: scott@airespace.com (Scott G. Kelly) Date: Wed, 25 Jun 2003 09:44:25 -0700 Subject: [Lwapp] key setup - current draft v. TLS References: Message-ID: <3EF9D169.6020600@airespace.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi David, Thanks for taking the time to prepare the comparison. Sorry for the delay in responding - I've been out of town and offline. I think the two approaches are comparable, but I have at least one concern with the tls approach below: it would require the AP to generate the symmetric key material. This means the AP must have a "good" rng. This was a primary consideration in the original lwapp design, since we aim to make APs as lightweight as possible. Since APs have no human interfaces under normal circumstances, I think conventional non-hardware-based methods of gathering randomness may not apply here, meaning the AP would nominally require a hardware rng for key generation (our AR has one, but not the AP). However, I'm not an expert in this area, so I may be missing something. One other design assumption we initially made was that there would not be any ciphersuite negotiation, although this has obvious implications if 128-bit AES is broken, so this would seem to make an argument for supporting at least a very simple negotiation (e.g. one side says "I support x or y", and the other side says "okay, let's do y"), but maybe not a more complex negotiation like tls does. And thirdly, it seems like we should support some non-pki authentication mechanism (shared secret), which tls does not support, as far as I know. So, to summarize, I think the tls approach seems to have only a little more overhead (1 extra round trip, which doesn't seem like a big deal for this application), but there are some subtleties in our requirements which it may not adequately address, unless modified. Maybe we should spend some time defining the requirements a bit better. It may be that our (airespace's) initial requirements aren't general enough. There are other key establishment methods which might also be worth considering. Scott David Molnar wrote: | Hi, | | Here's a performance comparison of the key setup stage in the current | draft with the setup in TLS. I'm going to consider plain TLS right now as | in Rescorla's book _SSL and TLS_ - from looking at the EAP-TLS spec, it | doesn't look like they make any major changes to the handshake. | | I will go through the diagrams for both protocols, then give a summary of | the required operations in each case. | | In the current LWAPP draft, the key setup looks like | | AP -----------------------> AR | JOIN(APCert, SessionID) | | AP <----------------------- AR | (ARCert, C1, S1, SessionID) | | where C1 consists of the AR's session key encrypted with the AP's public | key, and S1 is the signature of C1 concatenated with the sessionID. | | Total cost: 1 roundtrip, | 1 encryption for AR, | 1 signature for AR, | 1 decryption for AP, | 1 signature verification for AP, | plus overhead for assembling messages, checking sessionID. | | | In TLS mutual authentication, it looks like | | AP -----------------------> AR | ClientHello, Ciphersuites | | | AP <----------------------- AR | ServerHello, SessionID, | Ciphersuites, Certificate, | CertificateRequest, ServerHelloDone | | | AP -----------------------> AR | Certificate, ClientKeyExchange, | CertificateVerify, ChangeCipherSpec, | HandshakeFinished | | AP <----------------------- AR | ChangeCipherSpec, | HandshakeFinished | | I won't go through all the messages, but the really important ones are | ClientKeyExchange, which consists of the keying material encrypted with | the AR's public key, and the CertificateVerify, which consists of a MAC of | the handshake messages signed by the AP's private key. | | Total cost: 2 roundtrips, | 1 decryption by AR, | 1 signature verification by AR, | 1 encryption by AP, | 1 signature by AP, | plus overhead for assembling messages, | checking MAC, checking sessionID. | | | Does this look correct, given other peoples' understanding of the LWAPP | draft and TLS? | | As to how they compare, it's worth noting that we can pick a public-key | algorithm, such as RSA with e=3, where encryption and signature | verification is relatively fast. Usually in these cases decryption and | signature generation are the "heavyweight" operations. Both TLS and the | LWAPP draft have one such heavyweight operation for the AP - TLS makes the | AP sign something, while LWAPP has the AP decrypt S1. Similarly, both have | one heavyweight operation on the AR side - TLS has a decryption by the AR, | while the current draft has a signature generation by the AR. | | So what do people think about the relative costs of these two protocols? | | -David | _______________________________________________ | Lwapp mailing list | Lwapp@frascone.com | http://mail.frascone.com/mailman/listinfo/lwapp -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE++dFoMtIdhO0pgN4RAs+LAKDsSc5GeP1RO/8Ru6KIYq0i/MHuCACg5UVv ATYQXdwUM3e2RbabUzDUntY= =6O2t -----END PGP SIGNATURE----- From dmolnar@eecs.harvard.edu Wed Jun 25 18:28:32 2003 From: dmolnar@eecs.harvard.edu (David Molnar) Date: Wed, 25 Jun 2003 13:28:32 -0400 (EDT) Subject: [Lwapp] key setup - current draft v. TLS In-Reply-To: <3EF9D169.6020600@airespace.com> References: <3EF9D169.6020600@airespace.com> Message-ID: On Wed, 25 Jun 2003, Scott G. Kelly wrote: > apply here, meaning the AP would nominally require a hardware rng for > key generation (our AR has one, but not the AP). However, I'm not an > expert in this area, so I may be missing something. OK, I agree that this is an issue. A hardware RNG would be best. An alternative, however, to a hardware RNG might be to use a PRNG together with a random seed placed in the AP in such a way that the seed is inaccessible to the adversary. Then if the PRNG is good enough, it can "stretch" the random seed as much as desired for session key generation. For example, the seed might be placed in the AP at manufacture time, or might be configured as part of something that requires physical access to the AP. That may be too much of a burden, but the main point I want to make is that if we can get a very short secret seed on the AP, it can be stretched in software. > One other design assumption we initially made was that there would not > be any ciphersuite negotiation, although this has obvious implications > if 128-bit AES is broken, so this would seem to make an argument for > supporting at least a very simple negotiation (e.g. one side says "I > support x or y", and the other side says "okay, let's do y"), but maybe > not a more complex negotiation like tls does. And thirdly, it seems like I'm not sure that basic TLS is that much more complex than "I support x or y", "okay, let's do y." The ClientHello is accompanied by a list of ciphersuites supported, and the first server reply includes the "Okay, let's do y" message. There are several special features, such as Server Gated Cryptography, which require more complex negotiation, but those would not apply in the LWAPP context. One thing that the TLS negotiation *does* add over a really simple negotiation is that client and server exchange MACs of their negotiation messages after a key is established. This is required to prevent an active adversary from fooling the client and server into picking weaker encryption than otherwise would be used -- such attacks were present in SSL v2. > we should support some non-pki authentication mechanism (shared secret), > which tls does not support, as far as I know. We may want to check out this ietf-draft from Peter Gutmann on how to do TLS with shared secret keys: http://community.roxen.com/developers/idocs/drafts/draft-ietf-tls-sharedkeys-00.html or via tinyurl: http://tinyurl.com/f8td It's an application note that claims to support shared secret keys in TLS with a minimum of code change and no change to the protocol. > It may be that our (airespace's) initial requirements aren't general > enough. There are other key establishment methods which might also be > worth considering. Right. Nehru suggested IKE - perhaps another comparison is in order? I like TLS, however, because it does more than just key negotiation. TLS provides an entire transport layer, including secure control messages and some protection against session hijacking. -David From vsinha@foundrynet.com Wed Jun 25 19:37:48 2003 From: vsinha@foundrynet.com (Vishal Sinha) Date: Wed, 25 Jun 2003 11:37:48 -0700 Subject: [Lwapp] LWAPP L3 - one more time Message-ID: Pat, Multicast routing is not enabled on most layer 2 and some layer 3 boxes. Hence, I would not vote for this solution. Broadcasting is also a big turn off for most IT managers. I tend to like the static management solution more. For one thing, it gives us a more secure way of controlling which AR can be a part of the roaming domain. Also, for ease of configuration, IT manager can add a specific AR to the roaming domain at one centralized location like a NM server and the NM server can push the information to all the ARs within the domain. I know for sure that most of the NM servers have this capability. -Vishal Given that subscription has just exploded on this list, I'm going to = resend this question for those that were not on the list when I = originall sent it. I attempted to capture some Layer 3 (UDP) transport for LWAPP in the -02 draft. However, one thing that eludes me is how to do the WLAN switch discovery at Layer 3. Here are some thoughts that I've come up with, and would solicit input: 1. Multicast. The use of multicast to discovery WLAN switches across subnets seems very reasonable, except that all IT managers I've talked to disable multicast in their networks. 2. DHCP. It is possible to return a vendor specific DHCP extension. One=20 issue I've heard from a couple of sources is that in some instances DHCP servers are under the administration of another group from those responsible for WLAN service, and therefore this cannot be the only way. 3. DNS. Another mechanism, but this one does not necessarily provide geographical information, and therefore it could cause APs to associate with WLAN switches that are very far away. Not ideal. 4. Static Config. Certainly a viable method, but not very scalable. 5. SLP. Not much demand for SLP, and it suffers from many of the issues above. Thoughts? PatC From scott@airespace.com Wed Jun 25 20:21:02 2003 From: scott@airespace.com (Scott G. Kelly) Date: Wed, 25 Jun 2003 12:21:02 -0700 Subject: [Lwapp] key setup - current draft v. TLS References: <3EF9D169.6020600@airespace.com> Message-ID: <3EF9F61E.6000508@airespace.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi David, Comments inline... David Molnar wrote: | | On Wed, 25 Jun 2003, Scott G. Kelly wrote: | | |>apply here, meaning the AP would nominally require a hardware rng for |>key generation (our AR has one, but not the AP). However, I'm not an |>expert in this area, so I may be missing something. | | | OK, I agree that this is an issue. A hardware RNG would be best. An | alternative, however, to a hardware RNG might be to use a PRNG together | with a random seed placed in the AP in such a way that the seed is | inaccessible to the adversary. Then if the PRNG is good enough, it can | "stretch" the random seed as much as desired for session key generation. | | For example, the seed might be placed in the AP at manufacture time, or | might be configured as part of something that requires physical access to | the AP. That may be too much of a burden, but the main point I want to | make is that if we can get a very short secret seed on the AP, it can be | stretched in software. I don't like the idea of a single static prng seed even a little bit. We must assume that an adversary can determine what prng is in use. If new entropy is not stirred in periodically, the stream is predictable from any given point. For this reason, I think the key generation process should have a dynamic entropy source. We considered sending a prng seed from the AR to the AP as part of the exchange for this purpose, but in that case, why not just send the keys? |>One other design assumption we initially made was that there would not |>be any ciphersuite negotiation, although this has obvious implications |>if 128-bit AES is broken, so this would seem to make an argument for |>supporting at least a very simple negotiation (e.g. one side says "I |>support x or y", and the other side says "okay, let's do y"), but maybe |>not a more complex negotiation like tls does. And thirdly, it seems like | | | I'm not sure that basic TLS is that much more complex than "I support x or | y", "okay, let's do y." The ClientHello is accompanied by a list of | ciphersuites supported, and the first server reply includes the "Okay, | let's do y" message. | | There are several special features, such as Server Gated Cryptography, | which require more complex negotiation, but those would not apply in the | LWAPP context. One thing that the TLS negotiation *does* add over a really | simple negotiation is that client and server exchange MACs of their | negotiation messages after a key is established. This is required to | prevent an active adversary from fooling the client and server into | picking weaker encryption than otherwise would be used -- such attacks | were present in SSL v2. | | |>we should support some non-pki authentication mechanism (shared secret), |>which tls does not support, as far as I know. | | | We may want to check out this ietf-draft from Peter Gutmann on how to do | TLS with shared secret keys: | | http://community.roxen.com/developers/idocs/drafts/draft-ietf-tls-sharedkeys-00.html | | or via tinyurl: | http://tinyurl.com/f8td | | It's an application note that claims to support shared secret keys in TLS | with a minimum of code change and no change to the protocol. | | This is interesting. |>It may be that our (airespace's) initial requirements aren't general |>enough. There are other key establishment methods which might also be |>worth considering. | | | Right. Nehru suggested IKE - perhaps another comparison is in order? IKE is pretty IP specific, and is anything *but* lightweight. I hope we don't have to go there. | I like TLS, however, because it does more than just key negotiation. TLS | provides an entire transport layer, including secure control messages and | some protection against session hijacking. Again, I wonder if fleshing out requirements wouldn't be the most productive pursuit at this point. Your comment above sort of implies that we might want to encrypt/authenticate the entire AR<->AP data stream (commands and data), but we purposefully excluded data in our first pass (again, to keep the AP's lightweight). Scott -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE++fYeMtIdhO0pgN4RAoQGAKD18ktxD2R56endxxWeTCgrwx0cuQCfb6Qi aS6wPw4CwgzJ0Ve7e0JK/qY= =BJla -----END PGP SIGNATURE----- From vsinha@foundrynet.com Wed Jun 25 23:57:33 2003 From: vsinha@foundrynet.com (Vishal Sinha) Date: Wed, 25 Jun 2003 15:57:33 -0700 Subject: [Lwapp] Why LWAPP and not normal bridging!! Message-ID: Hello, According to the draft, "The AP forwards all received 802.11 frames to the AR via the LWAPP protocol, which processes the frames." What frames are we talking about here? Data frames, right! Why do we need to encapsulate the data frames within LWAPP. Most of the existing hardware will have to slow path forwarding of these frames. (Fast path is possible but won't be very cost effective in the beginning.) Instead, if APs do the bridging from 802.11 to 802.3 Ethernet frames, we won't need to upgrade the existing hardware. To sum up, my main question is about the rationale behind using LWAPP instead of 802.3 to transport user data frames. Thanks, Vishal From vsinha@foundrynet.com Thu Jun 26 00:55:06 2003 From: vsinha@foundrynet.com (Vishal Sinha) Date: Wed, 25 Jun 2003 16:55:06 -0700 Subject: [Lwapp] LWAPP L3 - one more time In-Reply-To: Message-ID: Sorry, I ventured in to a totally different domain of AR <--> AR discovery. For AP <--> AR discovery, I think multicast based discovery is fine as long as we enforce the presence of at least one AR within a L2 domain. We should totally rule out multicast routing support and static configuration. -Vishal -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On Behalf Of Vishal Sinha Sent: Wednesday, June 25, 2003 11:38 AM To: lwapp@frascone.com Subject: [Lwapp] LWAPP L3 - one more time Pat, Multicast routing is not enabled on most layer 2 and some layer 3 boxes. Hence, I would not vote for this solution. Broadcasting is also a big turn off for most IT managers. I tend to like the static management solution more. For one thing, it gives us a more secure way of controlling which AR can be a part of the roaming domain. Also, for ease of configuration, IT manager can add a specific AR to the roaming domain at one centralized location like a NM server and the NM server can push the information to all the ARs within the domain. I know for sure that most of the NM servers have this capability. -Vishal Given that subscription has just exploded on this list, I'm going to = resend this question for those that were not on the list when I = originall sent it. I attempted to capture some Layer 3 (UDP) transport for LWAPP in the -02 draft. However, one thing that eludes me is how to do the WLAN switch discovery at Layer 3. Here are some thoughts that I've come up with, and would solicit input: 1. Multicast. The use of multicast to discovery WLAN switches across subnets seems very reasonable, except that all IT managers I've talked to disable multicast in their networks. 2. DHCP. It is possible to return a vendor specific DHCP extension. One=20 issue I've heard from a couple of sources is that in some instances DHCP servers are under the administration of another group from those responsible for WLAN service, and therefore this cannot be the only way. 3. DNS. Another mechanism, but this one does not necessarily provide geographical information, and therefore it could cause APs to associate with WLAN switches that are very far away. Not ideal. 4. Static Config. Certainly a viable method, but not very scalable. 5. SLP. Not much demand for SLP, and it suffers from many of the issues above. Thoughts? PatC _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From pcalhoun@airespace.com Wed Jun 25 14:25:48 2003 From: pcalhoun@airespace.com (Pat Calhoun) Date: 25 Jun 2003 06:25:48 -0700 Subject: [Lwapp] Why LWAPP and not normal bridging!! In-Reply-To: References: Message-ID: <1056547548.11362.30.camel@dhcp-34-97.CS.Berkeley.EDU> > According to the draft, "The AP forwards all received 802.11 frames to > the AR via the LWAPP protocol, which processes the frames." What frames are > we talking about here? Data frames, right! Why do we need to encapsulate > the data frames within LWAPP. Most of the existing hardware will have to > slow path forwarding of these frames. (Fast path is possible but won't be > very cost effective in the beginning.) Instead, if APs do the bridging from > 802.11 to 802.3 Ethernet frames, we won't need to upgrade the existing > hardware. > > To sum up, my main question is about the rationale behind using LWAPP > instead of 802.3 to transport user data frames. Having direct access to the 802.11 frames provides a lot of data that can be used to "manage" the RF network (visibility into the RF characteristics of each packet can be very useful for many reasons). Further, MAC management frames will be needed in the central controller, and these are, of course, 802.11. Next, if one decides to centralize some security functions (e.g. WPA, RSN), then you need access to the raw 802.11 frame in the controller. The LWAPP spec does allow for this function to reside in the AP, though. PatC From vsinha@foundrynet.com Thu Jun 26 02:16:30 2003 From: vsinha@foundrynet.com (Vishal Sinha) Date: Wed, 25 Jun 2003 18:16:30 -0700 Subject: [Lwapp] Why LWAPP and not normal bridging!! In-Reply-To: <1056547548.11362.30.camel@dhcp-34-97.CS.Berkeley.EDU> Message-ID: Pat, This means that the packet will be processed twice in the software, first at AP and then at the AR before it reaches the destination. I see three potential disadvantages: 1. Bandwidth wastage (802.11 frame size - payload size.) 2. Difficult to apply session based policies in the hardware as these field will be buried deep inside the frame even if we can do hardware decapsulation of the frame. 3. Increased load on CPU and increased buffer requirement. We can achieve everything that you are looking for by separating the data & control information and using LWAPP only for the control information. For example, we can collect all the useful RF information and send them periodically to the AR(s) using LWAPP. Also for 802.11 management frames, we can terminate them at the AP and send separate control frames to the AR. One big advantage of this scheme is that it makes LWAPP more extensible. For example, if an AP supports IAPP and wants to send some information learned from another AP to the AR then a vendor can just define a new TLV and use it for their purpose. Finally, I cannot stress enough the importance of hardware forwarding of the data frames at the AR. Regards, -Vishal -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@airespace.com] Sent: Wednesday, June 25, 2003 6:26 AM To: Vishal Sinha Cc: LWAPP Subject: Re: [Lwapp] Why LWAPP and not normal bridging!! > According to the draft, "The AP forwards all received 802.11 frames to > the AR via the LWAPP protocol, which processes the frames." What frames are > we talking about here? Data frames, right! Why do we need to encapsulate > the data frames within LWAPP. Most of the existing hardware will have to > slow path forwarding of these frames. (Fast path is possible but won't be > very cost effective in the beginning.) Instead, if APs do the bridging from > 802.11 to 802.3 Ethernet frames, we won't need to upgrade the existing > hardware. > > To sum up, my main question is about the rationale behind using LWAPP > instead of 802.3 to transport user data frames. Having direct access to the 802.11 frames provides a lot of data that can be used to "manage" the RF network (visibility into the RF characteristics of each packet can be very useful for many reasons). Further, MAC management frames will be needed in the central controller, and these are, of course, 802.11. Next, if one decides to centralize some security functions (e.g. WPA, RSN), then you need access to the raw 802.11 frame in the controller. The LWAPP spec does allow for this function to reside in the AP, though. PatC From bhandaru@legra.com Thu Jun 26 03:41:30 2003 From: bhandaru@legra.com (Nehru Bhandaru) Date: Wed, 25 Jun 2003 22:41:30 -0400 Subject: [Lwapp] Why LWAPP and not normal bridging!! In-Reply-To: Message-ID: <00d201c33b8c$731593c0$7a0ba8c0@legra.com> Bridging 802.11 data frames to 802.3, while using lwapp for control = frames, will perhaps work if encryption/decryption is done at the AP.=20 I don't think this will work if AR performs the cryptographic=20 operations. Lwapp could allow this to be negotiated. - Nehru=20 -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On = Behalf Of Vishal Sinha Sent: Wednesday, June 25, 2003 9:17 PM To: Pat Calhoun Cc: LWAPP Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! Pat, This means that the packet will be processed twice in the software, = first at AP and then at the AR before it reaches the destination. I see three potential disadvantages: 1. Bandwidth wastage (802.11 frame size - = payload size.) 2. Difficult to apply session based policies in the hardware as these field will be buried deep inside the = frame even if we can do hardware decapsulation of the frame. 3. Increased load = on CPU and increased buffer requirement. We can achieve everything that you are looking for by separating the = data & control information and using LWAPP only for the control information. = For example, we can collect all the useful RF information and send them periodically to the AR(s) using LWAPP. Also for 802.11 management = frames, we can terminate them at the AP and send separate control frames to the AR. One big advantage of this scheme is that it makes LWAPP more extensible. = For example, if an AP supports IAPP and wants to send some information = learned from another AP to the AR then a vendor can just define a new TLV and = use it for their purpose. Finally, I cannot stress enough the importance of hardware forwarding of = the data frames at the AR. Regards, -Vishal -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@airespace.com] Sent: Wednesday, June 25, 2003 6:26 AM To: Vishal Sinha Cc: LWAPP Subject: Re: [Lwapp] Why LWAPP and not normal bridging!! > According to the draft, "The AP forwards all received 802.11 frames = > to the AR via the LWAPP protocol, which processes the frames." What=20 > frames are > we talking about here? Data frames, right! Why do we need to=20 > encapsulate the data frames within LWAPP. Most of the existing=20 > hardware will have to slow path forwarding of these frames. (Fast path = > is possible but won't be very cost effective in the beginning.)=20 > Instead, if APs do the bridging from > 802.11 to 802.3 Ethernet frames, we won't need to upgrade the existing = > hardware. > > To sum up, my main question is about the rationale behind using LWAPP=20 > instead of 802.3 to transport user data frames. Having direct access to the 802.11 frames provides a lot of data that = can be used to "manage" the RF network (visibility into the RF characteristics = of each packet can be very useful for many reasons). Further, MAC = management frames will be needed in the central controller, and these are, of = course, 802.11. Next, if one decides to centralize some security functions (e.g. WPA, RSN), then you need access to the raw 802.11 frame in the = controller. The LWAPP spec does allow for this function to reside in the AP, though. PatC _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From pcalhoun@airespace.com Thu Jun 26 15:16:44 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 26 Jun 2003 07:16:44 -0700 Subject: [Lwapp] LWAPP L3 - one more time Message-ID: <40301581B2962B448690A023EF16DFE157A3F4@bsn-mail-01.bstormnetworks.com> > Sorry, I ventured in to a totally different domain of AR <--> AR = discovery. > For AP <--> AR discovery, I think multicast based discovery is fine as = long > as we enforce the presence of at least one AR within a L2 domain. > We should totally rule out multicast routing support and static > configuration. But what about an AP/AR that reside on separate L2 domains? What I hear = from IT managers is that multicast is not routed, and it would therefore = not work for those types of deployments. PatC From isingh@chantrynetworks.com Thu Jun 26 15:40:28 2003 From: isingh@chantrynetworks.com (Inderpreet Singh) Date: Thu, 26 Jun 2003 10:40:28 -0400 Subject: [Lwapp] Layer 3 LWAPP In-Reply-To: <5.2.0.9.0.20030619185445.03859450@in.legra.com> Message-ID: <003001c33bf0$e38dd9a0$9d01a8c0@toronto.chantrynetworks.com> This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C33BCF.5C7C39A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I agree that the subject of "AP/AR discovery" is wider in scope than "centralized AP management over any network medium (not just L2)" as LWAPP has proposed. Therefore, just commenting on the potential discovery methods: 1. Multicast - as Pat states is not always routed so is confined to L2 2. DHCP - need of vendor specific extension doesn't really make it too standard 3. DNS - I agree with Pat..no location knowledge with this method. 4. Static config - I believe this must remain an option and must be left to the implementation. It's the same thing as mandating shared keys in IKE/IPsec knowing that it is not scalable. In this case mandating the option of statically configuring the IP address of the AR associated with an AP is reasonable from a standards view and interoperability testing in the early stages. 5. SLP - I don't know why you think "there is not much demand". Client discovery of printers via SLP is in wide use today. APs discovery of ARs can easily leverage SLP. The standards exist, its just a matter of configuring supported options on your DHCP server from the network perspective and it's the corresponding code on AR and AP's. Note that for AP IP addressing, we could similarly mandate either Static or DHCP IP addressing for the APs. -- Inderpreet Singh -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Michael Vakulenko Sent: Thursday, June 19, 2003 7:49 PM To: lwapp@frascone.com Subject: Re: [Lwapp] Layer 3 LWAPP At 10:06:58 -0700 17 Jun 2003, Pat R. Calhoun wrote: All, I attempted to capture some Layer 3 (UDP) transport for LWAPP in the -02 draft. However, one thing that eludes me is how to do the WLAN switch discovery at Layer 3. Here are some thoughts that I've come up with, and would solicit input: 1. Multicast. The use of multicast to discovery WLAN switches across subnets seems very reasonable, except that all IT managers I've talked to disable multicast in their networks. 2. DHCP. It is possible to return a vendor specific DHCP extension. One issue I've heard from a couple of sources is that in some instances DHCP servers are under the administration of another group from those responsible for WLAN service, and therefore this cannot be the only way. 3. DNS. Another mechanism, but this one does not necessarily provide geographical information, and therefore it could cause APs to associate with WLAN switches that are very far away. Not ideal. 4. Static Config. Certainly a viable method, but not very scalable. 5. SLP. Not much demand for SLP, and it suffers from many of the issues above. Thoughts? Looking on the list above, there is no single method that works well for all possible network configurations and AP connection scenarios. Furthermore, the whole issue of AR discovery really comes down to the question how AP obtains the IP address of the AR. The method of obtaining the address has nothing to do yet with communication between the AP and AR (which is the subject of the spec). As such, discovery method does not necessary have to be defined in the LWAPP spec. It's should be up to AP implementation to pick one method or another. The spec may recommend e.g., DHCP/DNS methods. The method by itself doesn't really affect the inter-operability of AR and AP. (Same way as e.g., FTP doesn't define how client gets the IP address of the server.) The LWAPP spec by itself should only define two types of messages that will facilitate the discovery process. 1. Discovery Request message, to which AR shall respond regardless of whether it was sent using broadcast or unicast destination address. 2. Redirection Message, upon reception of which AP shall attempt to connect to the AR pointed by the Redirection Message. This approach will leave enough flexibility for implementations, while keeping the spec simple. Comments? -- Michael V. PatC _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp ------=_NextPart_000_0031_01C33BCF.5C7C39A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree that the subject of = “AP/AR discovery” is wider in scope than “centralized AP management = over any network medium (not just L2)” as LWAPP has = proposed.

 

Therefore, just commenting on the potential discovery methods:

 

1. Multicast – as Pat states = is not always routed so is confined to L2

2. DHCP – need of vendor = specific extension doesn’t really make it too = standard

3. DNS – I agree with Pat..no location = knowledge with this method.

4. Static config – I believe this must remain an option and must be left to the implementation.  It’s = the same thing as mandating shared keys in IKE/IPsec = knowing that it is not scalable.  In this case mandating the option of statically configuring the IP address of = the AR associated with an AP is reasonable from a standards view and = interoperability testing in the early stages.

5. SLP – I don’t know = why you think “there is not much demand”.  Client discovery of printers via = SLP is in wide use today.  APs discovery of ARs  can = easily leverage SLP.  The = standards exist, its just a matter of configuring supported options = on your DHCP server from the network perspective and it’s the = corresponding code on AR and AP’s.

 

Note that for AP IP addressing, we = could similarly mandate either Static or DHCP IP addressing for the APs.

 

--

Inderpreet = Singh

 

-----Original = Message-----
From: = lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On = Behalf Of Michael Vakulenko
Sent: = Thursday, June 19, = 2003 7:49 PM
To: = lwapp@frascone.com
Subject: Re: [Lwapp] = Layer 3 LWAPP

 

At 10:06:58 -0700 17 Jun 2003, Pat R. Calhoun = wrote:

All,

I attempted to capture some Layer 3 (UDP) transport for LWAPP in the = -02
draft. However, one thing that eludes me is how to do the WLAN = switch
discovery at Layer 3. Here are some thoughts that I've come up with, = and
would solicit input:

1. Multicast. The use of multicast to discovery WLAN switches across
subnets seems very reasonable, except that all IT managers I've talked = to
disable multicast in their networks.
2. DHCP. It is possible to return a vendor specific DHCP extension. = One
issue I've heard from a couple of sources is that in some instances = DHCP
servers are under the administration of another group from those = responsible
for WLAN service, and therefore this cannot be the only way.
3. DNS. Another mechanism, but this one does not necessarily provide
geographical information, and therefore it could cause APs to associate = with
WLAN switches that are very far away. Not ideal.
4. Static Config. Certainly a viable method, but not very scalable.
5. SLP. Not much demand for SLP, and it suffers from many of the = issues
above.

Thoughts?


Looking on the list above, there is no single method that works well for = all possible network configurations and AP connection scenarios.

Furthermore, the whole issue of AR discovery really comes down to the = question how AP obtains the IP address of the AR. The method of obtaining the = address has nothing to do yet with communication between the AP and AR (which is = the subject of the spec). As such, discovery method does not necessary have = to be defined in the LWAPP spec.

It's should be up to AP implementation to pick one method or another. = The spec may recommend e.g., DHCP/DNS methods. The method by itself doesn't = really affect the inter-operability of AR and AP. (Same way as e.g., FTP = doesn't define how client gets the IP address of the server.)  

The LWAPP spec by itself should only define two types of messages that = will facilitate the discovery process.

1. Discovery Request message, to which AR shall respond regardless of = whether it was sent using broadcast or unicast destination address.

2. Redirection Message, upon reception of which AP shall attempt to = connect to the AR pointed by the Redirection Message.

This approach will leave enough flexibility for implementations, while = keeping the spec simple.

Comments?

-- Michael V.



PatC
_______________________________________________
Lwapp mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp

------=_NextPart_000_0031_01C33BCF.5C7C39A0-- From pcalhoun@airespace.com Thu Jun 26 15:52:01 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 26 Jun 2003 07:52:01 -0700 Subject: [Lwapp] Layer 3 LWAPP Message-ID: <40301581B2962B448690A023EF16DFE157A400@bsn-mail-01.bstormnetworks.com> > I agree that the subject of "AP/AR discovery" is wider in scope than > "centralized AP management over any network medium (not just L2)" as > LWAPP has proposed. > =20 > Therefore, just commenting on the potential discovery methods: > =20 > 1. Multicast - as Pat states is not always routed so is confined to L2 > 2. DHCP - need of vendor specific extension doesn't really make it too > standard Of course, it could be possible to create a DHCP extension - if this is = the path we wish to take > 3. DNS - I agree with Pat..no location knowledge with this method. > 4. Static config - I believe this must remain an option and must be = left > to the implementation. It's the same thing as mandating shared keys = in > IKE/IPsec knowing that it is not scalable. In this case mandating the > option of statically configuring the IP address of the AR associated > with an AP is reasonable from a standards view and interoperability > testing in the early stages. agreed. > 5. SLP - I don't know why you think "there is not much demand". = Client > discovery of printers via SLP is in wide use today. APs discovery of > ARs can easily leverage SLP. The standards exist, its just a matter = of > configuring supported options on your DHCP server from the network > perspective and it's the corresponding code on AR and AP's. Interesting. Perhaps things have changed in the past year. Last time I = spoke to Erik Guttman, that was not true. Sounded like Microsoft had = another method of doing service discovery. I believe Apple may be using = SLP, though. > Note that for AP IP addressing, we could similarly mandate either = Static > or DHCP IP addressing for the APs. Correct, but not sure this needs to be in the specification. PatC=20 From dmolnar@eecs.harvard.edu Thu Jun 26 16:22:39 2003 From: dmolnar@eecs.harvard.edu (David Molnar) Date: Thu, 26 Jun 2003 11:22:39 -0400 (EDT) Subject: [Lwapp] LWAPP requirements In-Reply-To: <3EF9F61E.6000508@airespace.com> References: <3EF9D169.6020600@airespace.com> <3EF9F61E.6000508@airespace.com> Message-ID: On Wed, 25 Jun 2003, Scott G. Kelly wrote: Hi Scott, I wanted to break out the discussion about requirements into a separate thread. I'll address your comments regarding PRNG seeding in another message. > | I like TLS, however, because it does more than just key negotiation. TLS > | provides an entire transport layer, including secure control messages and > | some protection against session hijacking. > > Again, I wonder if fleshing out requirements wouldn't be the most > productive pursuit at this point. Your comment above sort of implies > that we might want to encrypt/authenticate the entire AR<->AP data > stream (commands and data), but we purposefully excluded data in our > first pass (again, to keep the AP's lightweight). Oh, I'm sorry - I did *not* mean to imply that the data should be encrypted and authenticated. I do not see that as being LWAPP's job; data privacy is provided by WPA or 802.11i mechanisms. My comment about a transport layer with protection against session hijacking sprang from thinking about the control stream itself, excluding the data, as a session that requires secure transport. My point was only that there is more to building a secure protocol than securely exchanging the key. We then still have to specify secure methods for controlling a session, encrypting + authenticating data once the shared key is known, and so on. TLS has already looked at some of these issues. In terms of requirements, I think it is right to continue focus on control frames only. Does that seem correct to you? -David From pcalhoun@airespace.com Thu Jun 26 16:34:40 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 26 Jun 2003 08:34:40 -0700 Subject: [Lwapp] LWAPP requirements Message-ID: <40301581B2962B448690A023EF16DFE157A407@bsn-mail-01.bstormnetworks.com> > My point was only that there is more to building a secure protocol = than > securely exchanging the key. We then still have to specify secure = methods > for controlling a session, encrypting + authenticating data once the > shared key is known, and so on. TLS has already looked at some of = these > issues. Oh-oh... here we go again. TLS implies a reliable transport, and unless = we are looking at SCTP, then I'm not sure that TCP is agressive enough. = Again, LWAPP is typically run within a confined network, not the = internet, and is not subjected to the kind of packet loss or congestion = that one would expect from the larger network. This is not to say that = there is NO packet loss (or congestion), but rather that we need a = protocol that is agressive enough in its retransmissions to handle the = kind of application we are running. If we start looking at SCTP, which = *is* an alternative, then I think we can pretty much throw away LW and = call this APP :) > In terms of requirements, I think it is right to continue focus on = control > frames only. Does that seem correct to you? yes please PatC From scott@airespace.com Thu Jun 26 17:29:21 2003 From: scott@airespace.com (Scott G. Kelly) Date: Thu, 26 Jun 2003 09:29:21 -0700 Subject: [Lwapp] Re: LWAPP requirements References: <3EF9D169.6020600@airespace.com> <3EF9F61E.6000508@airespace.com> Message-ID: <3EFB1F61.8090909@airespace.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Molnar wrote: | In terms of requirements, I think it is right to continue focus on control | frames only. Does that seem correct to you? Yes. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE++x9hMtIdhO0pgN4RAg91AKDThKs60zn5oAXXrSnwlX6rfNqqmQCdFTrs Xh9EdjJjcl/QgnzMqDp/zr8= =3UBH -----END PGP SIGNATURE----- From vsinha@foundrynet.com Thu Jun 26 21:05:26 2003 From: vsinha@foundrynet.com (Vishal Sinha) Date: Thu, 26 Jun 2003 13:05:26 -0700 Subject: [Lwapp] Why LWAPP and not normal bridging!! In-Reply-To: <00d201c33b8c$731593c0$7a0ba8c0@legra.com> Message-ID: You are right! I am assuming that people would either want to do encryption/decryption at the AP or use some other security methods like IPSec or VPN. I don't see a practical reason why we should move this functionality to the AR considering the load we are putting on the CPU running on the AR. Remember that the AR may be supporting quite a few APs (>100) at a time. -Vishal -----Original Message----- From: Nehru Bhandaru [mailto:bhandaru@legra.com] Sent: Wednesday, June 25, 2003 7:42 PM To: 'Vishal Sinha'; 'Pat Calhoun' Cc: 'LWAPP' Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! Bridging 802.11 data frames to 802.3, while using lwapp for control frames, will perhaps work if encryption/decryption is done at the AP. I don't think this will work if AR performs the cryptographic operations. Lwapp could allow this to be negotiated. - Nehru -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Vishal Sinha Sent: Wednesday, June 25, 2003 9:17 PM To: Pat Calhoun Cc: LWAPP Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! Pat, This means that the packet will be processed twice in the software, first at AP and then at the AR before it reaches the destination. I see three potential disadvantages: 1. Bandwidth wastage (802.11 frame size - payload size.) 2. Difficult to apply session based policies in the hardware as these field will be buried deep inside the frame even if we can do hardware decapsulation of the frame. 3. Increased load on CPU and increased buffer requirement. We can achieve everything that you are looking for by separating the data & control information and using LWAPP only for the control information. For example, we can collect all the useful RF information and send them periodically to the AR(s) using LWAPP. Also for 802.11 management frames, we can terminate them at the AP and send separate control frames to the AR. One big advantage of this scheme is that it makes LWAPP more extensible. For example, if an AP supports IAPP and wants to send some information learned from another AP to the AR then a vendor can just define a new TLV and use it for their purpose. Finally, I cannot stress enough the importance of hardware forwarding of the data frames at the AR. Regards, -Vishal -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@airespace.com] Sent: Wednesday, June 25, 2003 6:26 AM To: Vishal Sinha Cc: LWAPP Subject: Re: [Lwapp] Why LWAPP and not normal bridging!! > According to the draft, "The AP forwards all received 802.11 frames > to the AR via the LWAPP protocol, which processes the frames." What > frames are > we talking about here? Data frames, right! Why do we need to > encapsulate the data frames within LWAPP. Most of the existing > hardware will have to slow path forwarding of these frames. (Fast path > is possible but won't be very cost effective in the beginning.) > Instead, if APs do the bridging from > 802.11 to 802.3 Ethernet frames, we won't need to upgrade the existing > hardware. > > To sum up, my main question is about the rationale behind using LWAPP > instead of 802.3 to transport user data frames. Having direct access to the 802.11 frames provides a lot of data that can be used to "manage" the RF network (visibility into the RF characteristics of each packet can be very useful for many reasons). Further, MAC management frames will be needed in the central controller, and these are, of course, 802.11. Next, if one decides to centralize some security functions (e.g. WPA, RSN), then you need access to the raw 802.11 frame in the controller. The LWAPP spec does allow for this function to reside in the AP, though. PatC _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From pcalhoun@airespace.com Thu Jun 26 21:13:58 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 26 Jun 2003 13:13:58 -0700 Subject: [Lwapp] Why LWAPP and not normal bridging!! Message-ID: <40301581B2962B448690A023EF16DFE157A426@bsn-mail-01.bstormnetworks.com> Vishal, The primary motivator for pushing encryption in the AR is to eliminate = the need to replace hundreds of APs up in ceilings in the event that = IEEE comes out with another standard (which could occur if the existing = security mechanism were found to be flawed). This is probably based on = experience with the whole WEP debacle.=20 In any case, terminating some L3 security protocol at the switch is a = fine idea as well. However, the number of APs being supported by the AR = is really not an issue because if one is terminating L3 at the AR you = have a similar problem. But again, the protocol is flexible in that the AR can decide whether = the AP should provide L2 encryption service or not - so if one prefers = to let the AP handle encryption services they would still be compliant = with the protocol. PatC -----Original Message----- From: Vishal Sinha [mailto:vsinha@foundrynet.com] Sent: Thu 6/26/2003 1:05 PM To: 'LWAPP' Cc:=09 Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! You are right! I am assuming that people would either want to do encryption/decryption at the AP or use some other security methods like IPSec or VPN. I don't see a practical reason why we should move this functionality to the AR considering the load we are putting on the CPU running on the AR. Remember that the AR may be supporting quite a few APs (>100) at a time. -Vishal -----Original Message----- From: Nehru Bhandaru [mailto:bhandaru@legra.com] Sent: Wednesday, June 25, 2003 7:42 PM To: 'Vishal Sinha'; 'Pat Calhoun' Cc: 'LWAPP' Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! Bridging 802.11 data frames to 802.3, while using lwapp for control = frames, will perhaps work if encryption/decryption is done at the AP. I don't think this will work if AR performs the cryptographic operations. Lwapp could allow this to be negotiated. - Nehru -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On = Behalf Of Vishal Sinha Sent: Wednesday, June 25, 2003 9:17 PM To: Pat Calhoun Cc: LWAPP Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! Pat, This means that the packet will be processed twice in the software, = first at AP and then at the AR before it reaches the destination. I see three potential disadvantages: 1. Bandwidth wastage (802.11 frame size - = payload size.) 2. Difficult to apply session based policies in the hardware as these field will be buried deep inside the = frame even if we can do hardware decapsulation of the frame. 3. Increased load = on CPU and increased buffer requirement. We can achieve everything that you are looking for by separating the = data & control information and using LWAPP only for the control information. = For example, we can collect all the useful RF information and send them periodically to the AR(s) using LWAPP. Also for 802.11 management = frames, we can terminate them at the AP and send separate control frames to the AR. One big advantage of this scheme is that it makes LWAPP more extensible. = For example, if an AP supports IAPP and wants to send some information = learned from another AP to the AR then a vendor can just define a new TLV and = use it for their purpose. Finally, I cannot stress enough the importance of hardware forwarding of = the data frames at the AR. Regards, -Vishal -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@airespace.com] Sent: Wednesday, June 25, 2003 6:26 AM To: Vishal Sinha Cc: LWAPP Subject: Re: [Lwapp] Why LWAPP and not normal bridging!! > According to the draft, "The AP forwards all received 802.11 frames > to the AR via the LWAPP protocol, which processes the frames." What > frames are > we talking about here? Data frames, right! Why do we need to > encapsulate the data frames within LWAPP. Most of the existing > hardware will have to slow path forwarding of these frames. (Fast path > is possible but won't be very cost effective in the beginning.) > Instead, if APs do the bridging from > 802.11 to 802.3 Ethernet frames, we won't need to upgrade the existing > hardware. > > To sum up, my main question is about the rationale behind using LWAPP > instead of 802.3 to transport user data frames. Having direct access to the 802.11 frames provides a lot of data that = can be used to "manage" the RF network (visibility into the RF characteristics = of each packet can be very useful for many reasons). Further, MAC = management frames will be needed in the central controller, and these are, of = course, 802.11. Next, if one decides to centralize some security functions (e.g. WPA, RSN), then you need access to the raw 802.11 frame in the = controller. The LWAPP spec does allow for this function to reside in the AP, though. PatC _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From vsinha@foundrynet.com Thu Jun 26 21:48:35 2003 From: vsinha@foundrynet.com (Vishal Sinha) Date: Thu, 26 Jun 2003 13:48:35 -0700 Subject: [Lwapp] Why LWAPP and not normal bridging!! In-Reply-To: <40301581B2962B448690A023EF16DFE157A426@bsn-mail-01.bstormnetworks.com> Message-ID: Pat, I understand your point of ease of upgrade. But if the encryption/decryption has to be done in software at the AP then we can still upgrade the code on AP using some mechanisms like IBM Remote Program Load Protocol. As far as number of APs connected to an AR is concerned, I do my calculation as follows: Total additional load on the CPU because of (de)encryption at AR = ( ~30Mbps (802.11a) * number of APs attached to the box) For a box that has say 96 ports, the CPU would have to process approximately 96 * 30Mbps = ~ 3 Gbps. No single CPU can handle that type of additional load in near future, considering the fact that there is already a bunch of other stuff running in the box. To me, the solution is either to go for distributed (multi-processor based) processing or fast path processing. First choice will make the box very expensive and second one is already running the show! -Vishal -----Original Message----- From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] Sent: Thursday, June 26, 2003 1:14 PM To: Vishal Sinha; LWAPP Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! Vishal, The primary motivator for pushing encryption in the AR is to eliminate the need to replace hundreds of APs up in ceilings in the event that IEEE comes out with another standard (which could occur if the existing security mechanism were found to be flawed). This is probably based on experience with the whole WEP debacle. In any case, terminating some L3 security protocol at the switch is a fine idea as well. However, the number of APs being supported by the AR is really not an issue because if one is terminating L3 at the AR you have a similar problem. But again, the protocol is flexible in that the AR can decide whether the AP should provide L2 encryption service or not - so if one prefers to let the AP handle encryption services they would still be compliant with the protocol. PatC -----Original Message----- From: Vishal Sinha [mailto:vsinha@foundrynet.com] Sent: Thu 6/26/2003 1:05 PM To: 'LWAPP' Cc: Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! You are right! I am assuming that people would either want to do encryption/decryption at the AP or use some other security methods like IPSec or VPN. I don't see a practical reason why we should move this functionality to the AR considering the load we are putting on the CPU running on the AR. Remember that the AR may be supporting quite a few APs (>100) at a time. -Vishal -----Original Message----- From: Nehru Bhandaru [mailto:bhandaru@legra.com] Sent: Wednesday, June 25, 2003 7:42 PM To: 'Vishal Sinha'; 'Pat Calhoun' Cc: 'LWAPP' Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! Bridging 802.11 data frames to 802.3, while using lwapp for control frames, will perhaps work if encryption/decryption is done at the AP. I don't think this will work if AR performs the cryptographic operations. Lwapp could allow this to be negotiated. - Nehru -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Vishal Sinha Sent: Wednesday, June 25, 2003 9:17 PM To: Pat Calhoun Cc: LWAPP Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! Pat, This means that the packet will be processed twice in the software, first at AP and then at the AR before it reaches the destination. I see three potential disadvantages: 1. Bandwidth wastage (802.11 frame size - payload size.) 2. Difficult to apply session based policies in the hardware as these field will be buried deep inside the frame even if we can do hardware decapsulation of the frame. 3. Increased load on CPU and increased buffer requirement. We can achieve everything that you are looking for by separating the data & control information and using LWAPP only for the control information. For example, we can collect all the useful RF information and send them periodically to the AR(s) using LWAPP. Also for 802.11 management frames, we can terminate them at the AP and send separate control frames to the AR. One big advantage of this scheme is that it makes LWAPP more extensible. For example, if an AP supports IAPP and wants to send some information learned from another AP to the AR then a vendor can just define a new TLV and use it for their purpose. Finally, I cannot stress enough the importance of hardware forwarding of the data frames at the AR. Regards, -Vishal -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@airespace.com] Sent: Wednesday, June 25, 2003 6:26 AM To: Vishal Sinha Cc: LWAPP Subject: Re: [Lwapp] Why LWAPP and not normal bridging!! > According to the draft, "The AP forwards all received 802.11 frames > to the AR via the LWAPP protocol, which processes the frames." What > frames are > we talking about here? Data frames, right! Why do we need to > encapsulate the data frames within LWAPP. Most of the existing > hardware will have to slow path forwarding of these frames. (Fast path > is possible but won't be very cost effective in the beginning.) > Instead, if APs do the bridging from > 802.11 to 802.3 Ethernet frames, we won't need to upgrade the existing > hardware. > > To sum up, my main question is about the rationale behind using LWAPP > instead of 802.3 to transport user data frames. Having direct access to the 802.11 frames provides a lot of data that can be used to "manage" the RF network (visibility into the RF characteristics of each packet can be very useful for many reasons). Further, MAC management frames will be needed in the central controller, and these are, of course, 802.11. Next, if one decides to centralize some security functions (e.g. WPA, RSN), then you need access to the raw 802.11 frame in the controller. The LWAPP spec does allow for this function to reside in the AP, though. PatC _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From kempf@docomolabs-usa.com Thu Jun 26 21:48:04 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Thu, 26 Jun 2003 13:48:04 -0700 Subject: [Lwapp] Why LWAPP and not normal bridging!! References: Message-ID: <02f201c33c24$3dce10f0$636015ac@dclkempt40> What about using a cryptocoprocesor on the router? jak ----- Original Message ----- From: "Vishal Sinha" To: "LWAPP" Sent: Thursday, June 26, 2003 1:48 PM Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! > Pat, > > I understand your point of ease of upgrade. But if the > encryption/decryption > has to be done in software at the AP then we can still upgrade the code on > AP > using some mechanisms like IBM Remote Program Load Protocol. > > As far as number of APs connected to an AR is concerned, I do my calculation > as follows: > > Total additional load on the CPU because of (de)encryption at AR = > ( ~30Mbps (802.11a) * number of APs attached to the box) > > For a box that has say 96 ports, the CPU would have to > process approximately 96 * 30Mbps = ~ 3 Gbps. No single CPU can handle > that type of additional load in near future, considering > the fact that there is already a bunch of other stuff running > in the box. To me, the solution is either to go for distributed > (multi-processor based) processing or fast path processing. > First choice will make the box very expensive and second one > is already running the show! > > -Vishal > > > -----Original Message----- > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > Sent: Thursday, June 26, 2003 1:14 PM > To: Vishal Sinha; LWAPP > Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! > > > Vishal, > > The primary motivator for pushing encryption in the AR is to eliminate the > need to replace hundreds of APs up in ceilings in the event that IEEE comes > out with another standard (which could occur if the existing security > mechanism were found to be flawed). This is probably based on experience > with the whole WEP debacle. > > In any case, terminating some L3 security protocol at the switch is a fine > idea as well. However, the number of APs being supported by the AR is really > not an issue because if one is terminating L3 at the AR you have a similar > problem. > > But again, the protocol is flexible in that the AR can decide whether the AP > should provide L2 encryption service or not - so if one prefers to let the > AP handle encryption services they would still be compliant with the > protocol. > > > PatC > -----Original Message----- > From: Vishal Sinha [mailto:vsinha@foundrynet.com] > Sent: Thu 6/26/2003 1:05 PM > To: 'LWAPP' > Cc: > Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! > > You are right! I am assuming that people would either want to do > encryption/decryption at the AP or use some other security methods > like IPSec or VPN. I don't see a practical reason why we should > move this functionality to the AR considering the load we are > putting on the CPU running on the AR. Remember that the AR may be > supporting quite a few APs (>100) at a time. > > -Vishal > > > -----Original Message----- > From: Nehru Bhandaru [mailto:bhandaru@legra.com] > Sent: Wednesday, June 25, 2003 7:42 PM > To: 'Vishal Sinha'; 'Pat Calhoun' > Cc: 'LWAPP' > Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! > > > > Bridging 802.11 data frames to 802.3, while using lwapp for control frames, > will perhaps work if encryption/decryption is done at the AP. > I don't think this will work if AR performs the cryptographic > operations. Lwapp could allow this to be negotiated. > > - Nehru > > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf > Of Vishal Sinha > Sent: Wednesday, June 25, 2003 9:17 PM > To: Pat Calhoun > Cc: LWAPP > Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! > > > Pat, > > This means that the packet will be processed twice in the software, first > at AP and then at the AR before it reaches the destination. I see three > potential disadvantages: 1. Bandwidth wastage (802.11 frame size - payload > size.) 2. Difficult to apply session based > policies in the hardware as these field will be buried deep inside the frame > even if we can do hardware decapsulation of the frame. 3. Increased load on > CPU and increased buffer requirement. > > We can achieve everything that you are looking for by separating the data & > control information and using LWAPP only for the control information. For > example, we can collect all the useful RF information and send them > periodically to the AR(s) using LWAPP. Also for 802.11 management frames, we > can terminate them at the AP and send separate control frames to the AR. > > One big advantage of this scheme is that it makes LWAPP more extensible. For > example, if an AP supports IAPP and wants to send some information learned > from another AP to the AR then a vendor can just define a new TLV and use it > for their purpose. > > Finally, I cannot stress enough the importance of hardware forwarding of the > data frames at the AR. > > Regards, > -Vishal > > > > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@airespace.com] > Sent: Wednesday, June 25, 2003 6:26 AM > To: Vishal Sinha > Cc: LWAPP > Subject: Re: [Lwapp] Why LWAPP and not normal bridging!! > > > > According to the draft, "The AP forwards all received 802.11 frames > > to the AR via the LWAPP protocol, which processes the frames." What > > frames > are > > we talking about here? Data frames, right! Why do we need to > > encapsulate the data frames within LWAPP. Most of the existing > > hardware will have to slow path forwarding of these frames. (Fast path > > is possible but won't be very cost effective in the beginning.) > > Instead, if APs do the bridging > from > > 802.11 to 802.3 Ethernet frames, we won't need to upgrade the existing > > hardware. > > > > To sum up, my main question is about the rationale behind using LWAPP > > instead of 802.3 to transport user data frames. > > Having direct access to the 802.11 frames provides a lot of data that can be > used to "manage" the RF network (visibility into the RF characteristics of > each packet can be very useful for many reasons). Further, MAC management > frames will be needed in the central controller, and these are, of course, > 802.11. Next, if one decides to centralize some security functions (e.g. > WPA, RSN), then you need access to the raw 802.11 frame in the controller. > The LWAPP spec does allow for this function to reside in the AP, though. > > PatC > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > From vsinha@foundrynet.com Thu Jun 26 21:58:59 2003 From: vsinha@foundrynet.com (Vishal Sinha) Date: Thu, 26 Jun 2003 13:58:59 -0700 Subject: [Lwapp] Why LWAPP and not normal bridging!! In-Reply-To: <02f201c33c24$3dce10f0$636015ac@dclkempt40> Message-ID: I am not very familiar with the functionality of a cryptoprocessor. Can they do bridging too? What about the ability to remove LWAPP header and put 802.3 header? I guess what I am asking is that with the help of cryptoprocessor can we avoid sending all the LWAPP data packets to the CPU? -Vishal -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Thursday, June 26, 2003 1:48 PM To: Vishal Sinha; LWAPP Subject: Re: [Lwapp] Why LWAPP and not normal bridging!! What about using a cryptocoprocesor on the router? jak ----- Original Message ----- From: "Vishal Sinha" To: "LWAPP" Sent: Thursday, June 26, 2003 1:48 PM Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! > Pat, > > I understand your point of ease of upgrade. But if the > encryption/decryption > has to be done in software at the AP then we can still upgrade the code on > AP > using some mechanisms like IBM Remote Program Load Protocol. > > As far as number of APs connected to an AR is concerned, I do my calculation > as follows: > > Total additional load on the CPU because of (de)encryption at AR = > ( ~30Mbps (802.11a) * number of APs attached to the box) > > For a box that has say 96 ports, the CPU would have to > process approximately 96 * 30Mbps = ~ 3 Gbps. No single CPU can handle > that type of additional load in near future, considering > the fact that there is already a bunch of other stuff running > in the box. To me, the solution is either to go for distributed > (multi-processor based) processing or fast path processing. > First choice will make the box very expensive and second one > is already running the show! > > -Vishal > > > -----Original Message----- > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > Sent: Thursday, June 26, 2003 1:14 PM > To: Vishal Sinha; LWAPP > Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! > > > Vishal, > > The primary motivator for pushing encryption in the AR is to eliminate the > need to replace hundreds of APs up in ceilings in the event that IEEE comes > out with another standard (which could occur if the existing security > mechanism were found to be flawed). This is probably based on experience > with the whole WEP debacle. > > In any case, terminating some L3 security protocol at the switch is a fine > idea as well. However, the number of APs being supported by the AR is really > not an issue because if one is terminating L3 at the AR you have a similar > problem. > > But again, the protocol is flexible in that the AR can decide whether the AP > should provide L2 encryption service or not - so if one prefers to let the > AP handle encryption services they would still be compliant with the > protocol. > > > PatC > -----Original Message----- > From: Vishal Sinha [mailto:vsinha@foundrynet.com] > Sent: Thu 6/26/2003 1:05 PM > To: 'LWAPP' > Cc: > Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! > > You are right! I am assuming that people would either want to do > encryption/decryption at the AP or use some other security methods > like IPSec or VPN. I don't see a practical reason why we should > move this functionality to the AR considering the load we are > putting on the CPU running on the AR. Remember that the AR may be > supporting quite a few APs (>100) at a time. > > -Vishal > > > -----Original Message----- > From: Nehru Bhandaru [mailto:bhandaru@legra.com] > Sent: Wednesday, June 25, 2003 7:42 PM > To: 'Vishal Sinha'; 'Pat Calhoun' > Cc: 'LWAPP' > Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! > > > > Bridging 802.11 data frames to 802.3, while using lwapp for control frames, > will perhaps work if encryption/decryption is done at the AP. > I don't think this will work if AR performs the cryptographic > operations. Lwapp could allow this to be negotiated. > > - Nehru > > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf > Of Vishal Sinha > Sent: Wednesday, June 25, 2003 9:17 PM > To: Pat Calhoun > Cc: LWAPP > Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! > > > Pat, > > This means that the packet will be processed twice in the software, first > at AP and then at the AR before it reaches the destination. I see three > potential disadvantages: 1. Bandwidth wastage (802.11 frame size - payload > size.) 2. Difficult to apply session based > policies in the hardware as these field will be buried deep inside the frame > even if we can do hardware decapsulation of the frame. 3. Increased load on > CPU and increased buffer requirement. > > We can achieve everything that you are looking for by separating the data & > control information and using LWAPP only for the control information. For > example, we can collect all the useful RF information and send them > periodically to the AR(s) using LWAPP. Also for 802.11 management frames, we > can terminate them at the AP and send separate control frames to the AR. > > One big advantage of this scheme is that it makes LWAPP more extensible. For > example, if an AP supports IAPP and wants to send some information learned > from another AP to the AR then a vendor can just define a new TLV and use it > for their purpose. > > Finally, I cannot stress enough the importance of hardware forwarding of the > data frames at the AR. > > Regards, > -Vishal > > > > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@airespace.com] > Sent: Wednesday, June 25, 2003 6:26 AM > To: Vishal Sinha > Cc: LWAPP > Subject: Re: [Lwapp] Why LWAPP and not normal bridging!! > > > > According to the draft, "The AP forwards all received 802.11 frames > > to the AR via the LWAPP protocol, which processes the frames." What > > frames > are > > we talking about here? Data frames, right! Why do we need to > > encapsulate the data frames within LWAPP. Most of the existing > > hardware will have to slow path forwarding of these frames. (Fast path > > is possible but won't be very cost effective in the beginning.) > > Instead, if APs do the bridging > from > > 802.11 to 802.3 Ethernet frames, we won't need to upgrade the existing > > hardware. > > > > To sum up, my main question is about the rationale behind using LWAPP > > instead of 802.3 to transport user data frames. > > Having direct access to the 802.11 frames provides a lot of data that can be > used to "manage" the RF network (visibility into the RF characteristics of > each packet can be very useful for many reasons). Further, MAC management > frames will be needed in the central controller, and these are, of course, > 802.11. Next, if one decides to centralize some security functions (e.g. > WPA, RSN), then you need access to the raw 802.11 frame in the controller. > The LWAPP spec does allow for this function to reside in the AP, though. > > PatC > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > From vsinha@foundrynet.com Thu Jun 26 21:59:36 2003 From: vsinha@foundrynet.com (Vishal Sinha) Date: Thu, 26 Jun 2003 13:59:36 -0700 Subject: [Lwapp] Layer 3 LWAPP In-Reply-To: <003001c33bf0$e38dd9a0$9d01a8c0@toronto.chantrynetworks.com> Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C33BEB.2D8C7940 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit For an IT manager deploying and managing 20 or more APs, it will be a real pain to statically configure stuff on a per AP basis. I think multicast is the way to go. To overcome the limitation of single L2 domain, we can add some feature to LWAPP so that AR can proxy for this AP and talk IP unicast with all the other ARs in the roaming domain. For example: AP1 should send out a L2 multicast packet and AR1 located with in the same L2 domain would receive it. Since AR1 knows about all the other AR's with in the roaming domain (through some different method), it should go through the list of all known ARs and send an IP packet with destination IP address as that of Arcs (in different l2 domain) and source IP address as that of the AP. ARx on receiving this DISCOVERY message should reply via IP unicast to the AP1. ---------------------------------------------------------------------------- -------------------------------------------------------------------------- I am making an assumption here that each AP will also have a routable IP Address. This *may* be needed for SNMP too. -Vishal -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On Behalf Of Inderpreet Singh Sent: Thursday, June 26, 2003 7:40 AM To: 'Michael Vakulenko'; lwapp@frascone.com Subject: RE: [Lwapp] Layer 3 LWAPP I agree that the subject of "AP/AR discovery" is wider in scope than "centralized AP management over any network medium (not just L2)" as LWAPP has proposed. Therefore, just commenting on the potential discovery methods: 1. Multicast - as Pat states is not always routed so is confined to L2 2. DHCP - need of vendor specific extension doesn't really make it too standard 3. DNS - I agree with Pat..no location knowledge with this method. 4. Static config - I believe this must remain an option and must be left to the implementation. It's the same thing as mandating shared keys in IKE/IPsec knowing that it is not scalable. In this case mandating the option of statically configuring the IP address of the AR associated with an AP is reasonable from a standards view and interoperability testing in the early stages. 5. SLP - I don't know why you think "there is not much demand". Client discovery of printers via SLP is in wide use today. APs discovery of ARs can easily leverage SLP. The standards exist, its just a matter of configuring supported options on your DHCP server from the network perspective and it's the corresponding code on AR and AP's. Note that for AP IP addressing, we could similarly mandate either Static or DHCP IP addressing for the APs. -- Inderpreet Singh -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Michael Vakulenko Sent: Thursday, June 19, 2003 7:49 PM To: lwapp@frascone.com Subject: Re: [Lwapp] Layer 3 LWAPP At 10:06:58 -0700 17 Jun 2003, Pat R. Calhoun wrote: All, I attempted to capture some Layer 3 (UDP) transport for LWAPP in the -02 draft. However, one thing that eludes me is how to do the WLAN switch discovery at Layer 3. Here are some thoughts that I've come up with, and would solicit input: 1. Multicast. The use of multicast to discovery WLAN switches across subnets seems very reasonable, except that all IT managers I've talked to disable multicast in their networks. 2. DHCP. It is possible to return a vendor specific DHCP extension. One issue I've heard from a couple of sources is that in some instances DHCP servers are under the administration of another group from those responsible for WLAN service, and therefore this cannot be the only way. 3. DNS. Another mechanism, but this one does not necessarily provide geographical information, and therefore it could cause APs to associate with WLAN switches that are very far away. Not ideal. 4. Static Config. Certainly a viable method, but not very scalable. 5. SLP. Not much demand for SLP, and it suffers from many of the issues above. Thoughts? Looking on the list above, there is no single method that works well for all possible network configurations and AP connection scenarios. Furthermore, the whole issue of AR discovery really comes down to the question how AP obtains the IP address of the AR. The method of obtaining the address has nothing to do yet with communication between the AP and AR (which is the subject of the spec). As such, discovery method does not necessary have to be defined in the LWAPP spec. It's should be up to AP implementation to pick one method or another. The spec may recommend e.g., DHCP/DNS methods. The method by itself doesn't really affect the inter-operability of AR and AP. (Same way as e.g., FTP doesn't define how client gets the IP address of the server.) The LWAPP spec by itself should only define two types of messages that will facilitate the discovery process. 1. Discovery Request message, to which AR shall respond regardless of whether it was sent using broadcast or unicast destination address. 2. Redirection Message, upon reception of which AP shall attempt to connect to the AR pointed by the Redirection Message. This approach will leave enough flexibility for implementations, while keeping the spec simple. Comments? -- Michael V. PatC _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp ------=_NextPart_000_0063_01C33BEB.2D8C7940 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
For=20 an IT manager deploying and managing 20 or more APs, it will be a = real pain=20 to statically
configure stuff on a per AP basis. =
 
I=20 think multicast is the way to go. To overcome the limitation of single = L2=20 domain, we can
add=20 some feature to LWAPP so that AR can proxy for this AP and=20 talk IP unicast with 
all=20 the other ARs in the roaming domain.
 
For=20 example:
 
AP1=20 should send out a L2 multicast packet and AR1 located with in the same = L2=20 domain would receive it.
Since=20 AR1 knows about all the other AR's with in the roaming domain (through = some=20 different method),
it should go through the list of=20 all known ARs and send an IP packet with = destination IP=20 address as that
of=20 Arcs (in different l2 domain) and source IP address as that = of the AP.=20 ARx on receiving this DISCOVERY
message should reply via IP unicast = to the=20 AP1.
 
----------------------------------------------= -------------------------------------------------------------------------= -------------------------------
I am=20 making an assumption here that each AP will also have a routable IP = Address. This *may* be needed for
SNMP=20 too.
 
-Vishal 
 
 
-----Original Message-----
From: = lwapp-admin@frascone.com=20 [mailto:lwapp-admin@frascone.com]On Behalf Of Inderpreet=20 Singh
Sent: Thursday, June 26, 2003 7:40 AM
To: = 'Michael=20 Vakulenko'; lwapp@frascone.com
Subject: RE: [Lwapp] Layer 3=20 LWAPP

I agree = that the=20 subject of “AP/AR discovery” is wider in scope than = “centralized AP management=20 over any network medium (not just L2)” as LWAPP has=20 proposed.

 

Therefore, = just=20 commenting on the potential discovery = methods:

 

1. = Multicast – as Pat=20 states is not always routed so is confined to = L2

2. DHCP = – need of=20 vendor specific extension doesn’t really make it too=20 standard

3. DNS = – I agree with=20 Pat..no = location knowledge=20 with this method.

4. Static = config – I believe this must remain an = option and must be=20 left to the implementation.  = It’s=20 the same thing as mandating shared keys in IKE/IPsec=20 knowing that it is not scalable.  In this case mandating the = option of=20 statically configuring the IP address of the AR associated with an AP = is=20 reasonable from a standards view and interoperability testing in the = early=20 stages.

5. SLP = – I don’t know=20 why you think “there is not much demand”.  Client discovery of printers = via SLP is=20 in wide use today.  = APs discovery of ARs  can easily leverage = SLP.  The standards exist, its just a matter of configuring supported = options on your=20 DHCP server from the network perspective and it’s the = corresponding code on AR=20 and AP’s.

 

Note that = for AP IP=20 addressing, we could similarly mandate either Static or DHCP IP = addressing for=20 the APs.

 

--

Inderpreet=20 Singh

 

-----Original=20 Message-----
From:=20 lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf Of Michael=20 Vakulenko
Sent:=20 Thursday, June 19,=20 2003 = 7:49=20 PM
To: = lwapp@frascone.com
Subject: Re: [Lwapp] Layer 3=20 LWAPP

 

At 10:06:58 -0700 17 Jun = 2003, Pat R.=20 Calhoun wrote:

All,

I attempted to = capture some=20 Layer 3 (UDP) transport for LWAPP in the -02
draft. However, one = thing that=20 eludes me is how to do the WLAN switch
discovery at Layer 3. Here = are some=20 thoughts that I've come up with, and
would solicit input:

1. = Multicast. The use of multicast to discovery WLAN switches = across
subnets=20 seems very reasonable, except that all IT managers I've talked = to
disable=20 multicast in their networks.
2. DHCP. It is possible to return a = vendor=20 specific DHCP extension. One
issue I've heard from a couple of = sources is=20 that in some instances DHCP
servers are under the administration of = another=20 group from those responsible
for WLAN service, and therefore this = cannot be=20 the only way.
3. DNS. Another mechanism, but this one does not = necessarily=20 provide
geographical information, and therefore it could cause APs = to=20 associate with
WLAN switches that are very far away. Not = ideal.
4.=20 Static Config. Certainly a viable method, but not very scalable.
5. = SLP.=20 Not much demand for SLP, and it suffers from many of the=20 issues
above.

Thoughts?


Looking on the list = above, there is=20 no single method that works well for all possible network = configurations and=20 AP connection scenarios.

Furthermore, the whole issue of AR = discovery=20 really comes down to the question how AP obtains the IP address of the = AR. The=20 method of obtaining the address has nothing to do yet with = communication=20 between the AP and AR (which is the subject of the spec). As such, = discovery=20 method does not necessary have to be defined in the LWAPP spec. =

It's=20 should be up to AP implementation to pick one method or another. The = spec may=20 recommend e.g., DHCP/DNS methods. The method by itself doesn't really = affect=20 the inter-operability of AR and AP. (Same way as e.g., FTP doesn't = define how=20 client gets the IP address of the server.)  

The = LWAPP spec=20 by itself should only define two types of messages that will = facilitate the=20 discovery process.

1. Discovery Request message, to which AR = shall=20 respond regardless of whether it was sent using broadcast or unicast=20 destination address.

2. Redirection Message, upon reception of = which AP=20 shall attempt to connect to the AR pointed by the Redirection Message. =

This approach will leave enough flexibility for = implementations, while=20 keeping the spec simple.

Comments?

-- Michael = V.

PatC
_______________________________________________
Lwapp=20 mailing list
Lwapp@frascone.com
http://mail.frascone.com/mailman/listinfo/lwapp =

------=_NextPart_000_0063_01C33BEB.2D8C7940-- From pcalhoun@airespace.com Thu Jun 26 22:02:59 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 26 Jun 2003 14:02:59 -0700 Subject: [Lwapp] Why LWAPP and not normal bridging!! Message-ID: <40301581B2962B448690A023EF16DFE157A42D@bsn-mail-01.bstormnetworks.com> > I understand your point of ease of upgrade. But if the > encryption/decryption > has to be done in software at the AP then we can still upgrade the = code on > AP > using some mechanisms like IBM Remote Program Load Protocol. The primary issue is that historically such an upgrade requires a = hardware swap, not just a software upgrade :( > As far as number of APs connected to an AR is concerned, I do my=20 > calculation as follows: > Total additional load on the CPU because of (de)encryption at AR =3D > ( ~30Mbps (802.11a) * number of APs attached to the box) > For a box that has say 96 ports, the CPU would have to > process approximately 96 * 30Mbps =3D ~ 3 Gbps. No single CPU can = handle > that type of additional load in near future, considering > the fact that there is already a bunch of other stuff running > in the box. To me, the solution is either to go for distributed > (multi-processor based) processing or fast path processing. > First choice will make the box very expensive and second one > is already running the show! Hence why most implementations handle encryption in hardware, not = software (also why many folks leave this functionality in the AP since = the hardware for current encryption algorithms are readily available = there :) PatC From kempf@docomolabs-usa.com Thu Jun 26 21:58:52 2003 From: kempf@docomolabs-usa.com (James Kempf) Date: Thu, 26 Jun 2003 13:58:52 -0700 Subject: [Lwapp] Why LWAPP and not normal bridging!! References: Message-ID: <030601c33c25$bfbbd380$636015ac@dclkempt40> > I am not very familiar with the functionality of a cryptoprocessor. > Can they do bridging too? What about the ability to remove LWAPP > header and put 802.3 header? > > I guess what I am asking is that with the help of cryptoprocessor > can we avoid sending all the LWAPP data packets to the CPU? > > What I meant was, your previous posting seem to assume that the cryptographic calculations are being done on the CPU. They could also be done on a cryptographic co-processor, thus offloading that bit from the CPU. This wouldn't impact the framing/deframing though. jak From pcalhoun@airespace.com Thu Jun 26 22:05:06 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Thu, 26 Jun 2003 14:05:06 -0700 Subject: [Lwapp] Why LWAPP and not normal bridging!! Message-ID: <40301581B2962B448690A023EF16DFE157A42E@bsn-mail-01.bstormnetworks.com> > I am not very familiar with the functionality of a cryptoprocessor. > Can they do bridging too? What about the ability to remove LWAPP > header and put 802.3 header? Obviously some function is required in the data path to handle this = bridging. This could be handle by some specialized processor in the fast = path and does not need to be part of the crypto-processor. > I guess what I am asking is that with the help of cryptoprocessor > can we avoid sending all the LWAPP data packets to the CPU? Yes PatC From vsinha@foundrynet.com Thu Jun 26 22:15:36 2003 From: vsinha@foundrynet.com (Vishal Sinha) Date: Thu, 26 Jun 2003 14:15:36 -0700 Subject: [Lwapp] Why LWAPP and not normal bridging!! In-Reply-To: <40301581B2962B448690A023EF16DFE157A42E@bsn-mail-01.bstormnetworks.com> Message-ID: Pat, After talking to some customers, I got the feedback that most of them want to migrate slowly to Wi-Fi. They would like to retain their existing L2 and L3 switches/Routers and would prefer just a software upgrade. Anyway, I think LWAPP should make it optional to do encapsulation of data frames. -Vishal -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On Behalf Of Pat R. Calhoun Sent: Thursday, June 26, 2003 2:05 PM To: Vishal Sinha; James Kempf; LWAPP Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! > I am not very familiar with the functionality of a cryptoprocessor. > Can they do bridging too? What about the ability to remove LWAPP > header and put 802.3 header? Obviously some function is required in the data path to handle this bridging. This could be handle by some specialized processor in the fast path and does not need to be part of the crypto-processor. > I guess what I am asking is that with the help of cryptoprocessor > can we avoid sending all the LWAPP data packets to the CPU? Yes PatC _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From volpano@cranitesystems.net Thu Jun 26 23:07:11 2003 From: volpano@cranitesystems.net (Dennis Volpano) Date: Thu, 26 Jun 2003 15:07:11 -0700 (PDT) Subject: [Lwapp] Why LWAPP and not normal bridging!! In-Reply-To: Message-ID: Given the duty cycle of a typical AP, it turns out that for certain modes of operation for AES and wise choice of MAC algorithm, the expected rate for encryption + MAC is 150Mbps (1500 byte packets) in s/w running on a lowly 233MHz Pentium. This suggests that in practice, one could see an expected rate of 1.2Gbps in s/w on a 2GHz Pentium. Given the low duty cycle of the mgmt CPU on a typical 24-port edge switch then, it is certainly reasonable to consider terminating all L2 crypto from end stations in this bridge in s/w. This could also be useful if the bridge plans to support 802.1 MACSec. Dennis On Thu, 26 Jun 2003, Vishal Sinha wrote: > Pat, > > I understand your point of ease of upgrade. But if the > encryption/decryption > has to be done in software at the AP then we can still upgrade the code on > AP > using some mechanisms like IBM Remote Program Load Protocol. > > As far as number of APs connected to an AR is concerned, I do my calculation > as follows: > > Total additional load on the CPU because of (de)encryption at AR = > ( ~30Mbps (802.11a) * number of APs attached to the box) > > For a box that has say 96 ports, the CPU would have to > process approximately 96 * 30Mbps = ~ 3 Gbps. No single CPU can handle > that type of additional load in near future, considering > the fact that there is already a bunch of other stuff running > in the box. To me, the solution is either to go for distributed > (multi-processor based) processing or fast path processing. > First choice will make the box very expensive and second one > is already running the show! > > -Vishal > > > -----Original Message----- > From: Pat R. Calhoun [mailto:pcalhoun@airespace.com] > Sent: Thursday, June 26, 2003 1:14 PM > To: Vishal Sinha; LWAPP > Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! > > > Vishal, > > The primary motivator for pushing encryption in the AR is to eliminate the > need to replace hundreds of APs up in ceilings in the event that IEEE comes > out with another standard (which could occur if the existing security > mechanism were found to be flawed). This is probably based on experience > with the whole WEP debacle. > > In any case, terminating some L3 security protocol at the switch is a fine > idea as well. However, the number of APs being supported by the AR is really > not an issue because if one is terminating L3 at the AR you have a similar > problem. > > But again, the protocol is flexible in that the AR can decide whether the AP > should provide L2 encryption service or not - so if one prefers to let the > AP handle encryption services they would still be compliant with the > protocol. > > > PatC > -----Original Message----- > From: Vishal Sinha [mailto:vsinha@foundrynet.com] > Sent: Thu 6/26/2003 1:05 PM > To: 'LWAPP' > Cc: > Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! > > You are right! I am assuming that people would either want to do > encryption/decryption at the AP or use some other security methods > like IPSec or VPN. I don't see a practical reason why we should > move this functionality to the AR considering the load we are > putting on the CPU running on the AR. Remember that the AR may be > supporting quite a few APs (>100) at a time. > > -Vishal > > > -----Original Message----- > From: Nehru Bhandaru [mailto:bhandaru@legra.com] > Sent: Wednesday, June 25, 2003 7:42 PM > To: 'Vishal Sinha'; 'Pat Calhoun' > Cc: 'LWAPP' > Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! > > > > Bridging 802.11 data frames to 802.3, while using lwapp for control frames, > will perhaps work if encryption/decryption is done at the AP. > I don't think this will work if AR performs the cryptographic > operations. Lwapp could allow this to be negotiated. > > - Nehru > > -----Original Message----- > From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com] On Behalf > Of Vishal Sinha > Sent: Wednesday, June 25, 2003 9:17 PM > To: Pat Calhoun > Cc: LWAPP > Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! > > > Pat, > > This means that the packet will be processed twice in the software, first > at AP and then at the AR before it reaches the destination. I see three > potential disadvantages: 1. Bandwidth wastage (802.11 frame size - payload > size.) 2. Difficult to apply session based > policies in the hardware as these field will be buried deep inside the frame > even if we can do hardware decapsulation of the frame. 3. Increased load on > CPU and increased buffer requirement. > > We can achieve everything that you are looking for by separating the data & > control information and using LWAPP only for the control information. For > example, we can collect all the useful RF information and send them > periodically to the AR(s) using LWAPP. Also for 802.11 management frames, we > can terminate them at the AP and send separate control frames to the AR. > > One big advantage of this scheme is that it makes LWAPP more extensible. For > example, if an AP supports IAPP and wants to send some information learned > from another AP to the AR then a vendor can just define a new TLV and use it > for their purpose. > > Finally, I cannot stress enough the importance of hardware forwarding of the > data frames at the AR. > > Regards, > -Vishal > > > > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@airespace.com] > Sent: Wednesday, June 25, 2003 6:26 AM > To: Vishal Sinha > Cc: LWAPP > Subject: Re: [Lwapp] Why LWAPP and not normal bridging!! > > > > According to the draft, "The AP forwards all received 802.11 frames > > to the AR via the LWAPP protocol, which processes the frames." What > > frames > are > > we talking about here? Data frames, right! Why do we need to > > encapsulate the data frames within LWAPP. Most of the existing > > hardware will have to slow path forwarding of these frames. (Fast path > > is possible but won't be very cost effective in the beginning.) > > Instead, if APs do the bridging > from > > 802.11 to 802.3 Ethernet frames, we won't need to upgrade the existing > > hardware. > > > > To sum up, my main question is about the rationale behind using LWAPP > > instead of 802.3 to transport user data frames. > > Having direct access to the 802.11 frames provides a lot of data that can be > used to "manage" the RF network (visibility into the RF characteristics of > each packet can be very useful for many reasons). Further, MAC management > frames will be needed in the central controller, and these are, of course, > 802.11. Next, if one decides to centralize some security functions (e.g. > WPA, RSN), then you need access to the raw 802.11 frame in the controller. > The LWAPP spec does allow for this function to reside in the AP, though. > > PatC > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > > > > _______________________________________________ > Lwapp mailing list > Lwapp@frascone.com > http://mail.frascone.com/mailman/listinfo/lwapp > From alper@docomolabs-usa.com Fri Jun 27 07:45:52 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Thu, 26 Jun 2003 23:45:52 -0700 Subject: [Lwapp] Why LWAPP and not normal bridging!! In-Reply-To: <40301581B2962B448690A023EF16DFE157A426@bsn-mail-01.bstormnetworks.com> Message-ID: > The primary motivator for pushing encryption in the AR is to eliminate the > need to replace hundreds of APs up in ceilings in the event that IEEE comes > out with another standard (which could occur if the existing security > mechanism were found to be flawed). This is probably based on experience with > the whole WEP debacle. That sounds like a good reason to use PANA in here..... Alper From Mike.Moreton@Synad.com Fri Jun 27 09:23:22 2003 From: Mike.Moreton@Synad.com (Mike Moreton) Date: Fri, 27 Jun 2003 09:23:22 +0100 Subject: [Lwapp] Why LWAPP and not normal bridging!! Message-ID: <0D3F1B25E75EE24483A6E69201142C867DA009@paris.synad.com> Vishal, Yes, many people who don't currently have 802.11 but do have a big Ethernet installation will want a very gradual migration. But there are also people who are installing huge 802.11 networks in one go, and they have very different needs. Mike Moreton Synad Technologies Ltd. =20 -----Original Message----- From: Vishal Sinha [mailto:vsinha@foundrynet.com]=20 Sent: 26 June 2003 22:16 To: LWAPP Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! Pat, After talking to some customers, I got the feedback that most of them want to migrate slowly to Wi-Fi. They would like to retain their existing L2 and L3 switches/Routers and would prefer just a software upgrade. Anyway, I think LWAPP should make it optional to do encapsulation of data frames. -Vishal -----Original Message----- From: lwapp-admin@frascone.com [mailto:lwapp-admin@frascone.com]On Behalf Of Pat R. Calhoun Sent: Thursday, June 26, 2003 2:05 PM To: Vishal Sinha; James Kempf; LWAPP Subject: RE: [Lwapp] Why LWAPP and not normal bridging!! > I am not very familiar with the functionality of a cryptoprocessor. > Can they do bridging too? What about the ability to remove LWAPP > header and put 802.3 header? Obviously some function is required in the data path to handle this bridging. This could be handle by some specialized processor in the fast path and does not need to be part of the crypto-processor. > I guess what I am asking is that with the help of cryptoprocessor > can we avoid sending all the LWAPP data packets to the CPU? Yes PatC _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp _______________________________________________ Lwapp mailing list Lwapp@frascone.com http://mail.frascone.com/mailman/listinfo/lwapp From pcalhoun@airespace.com Fri Jun 27 14:22:33 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Fri, 27 Jun 2003 06:22:33 -0700 Subject: [Lwapp] Why LWAPP and not normal bridging!! Message-ID: <40301581B2962B448690A023EF16DFE1DC4F2A@bsn-mail-01.bstormnetworks.com> >> The primary motivator for pushing encryption in the AR is to = eliminate the >> need to replace hundreds of APs up in ceilings in the event that IEEE = comes >> out with another standard (which could occur if the existing security >> mechanism were found to be flawed). This is probably based on = experience with >> the whole WEP debacle. > >That sounds like a good reason to use PANA in here..... PANA can't help upgrade AP firmware. PatC From alper@docomolabs-usa.com Fri Jun 27 19:49:39 2003 From: alper@docomolabs-usa.com (Alper Yegin) Date: Fri, 27 Jun 2003 11:49:39 -0700 Subject: [Lwapp] Why LWAPP and not normal bridging!! In-Reply-To: <40301581B2962B448690A023EF16DFE1DC4F2A@bsn-mail-01.bstormnetworks.com> Message-ID: >>> The primary motivator for pushing encryption in the AR is to eliminate the >>> need to replace hundreds of APs up in ceilings in the event that IEEE comes >>> out with another standard (which could occur if the existing security >>> mechanism were found to be flawed). This is probably based on experience >>> with >>> the whole WEP debacle. >> >> That sounds like a good reason to use PANA in here..... > > PANA can't help upgrade AP firmware. That is not what I am suggesting. If there is a problem or risk with using link-layer authentication and ciphering, and if you think the solution is to perform these operations on the access router, then you can use PANA for that. PANA enables you to do the authentication exchange between the host and the access router. You can use it to enable link-layer ciphers. But if you don't even want to use L2 ciphers, then you can use PANA to enable IPsec-based per-packet access control in your access network. Alper From pcalhoun@airespace.com Fri Jun 27 21:35:05 2003 From: pcalhoun@airespace.com (Pat R. Calhoun) Date: Fri, 27 Jun 2003 13:35:05 -0700 Subject: [Lwapp] Why LWAPP and not normal bridging!! Message-ID: <40301581B2962B448690A023EF16DFE1DC4F3D@bsn-mail-01.bstormnetworks.com> >> PANA can't help upgrade AP firmware. >=20 > That is not what I am suggesting. >=20 > If there is a problem or risk with using link-layer authentication and > ciphering, and if you think the solution is to perform these = operations on > the access router, then you can use PANA for that. PANA enables you to = do > the authentication exchange between the host and the access router. = You can > use it to enable link-layer ciphers. But if you don't even want to use = L2 > ciphers, then you can use PANA to enable IPsec-based per-packet access > control in your access network. I think this discussion is required in the PANA mailing list, so I will = refrain from contributing to cross-mailing list discussions, but suffice = it to say that IPSec and L2 mechanisms already exist, so adding another = level of negotiation on existing clients makes it rather difficult to = deploy. But I will admit that I am completely out of touch as to the = latest progress that PANA has made since the last BOF. PatC