> From: Raghu [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 11, 2002 3:10 AM > > Henrik Eriksson wrote: > > >>From: Raghu [mailto:[EMAIL PROTECTED]] > >>Sent: Tuesday, July 09, 2002 7:35 PM > >> > >> > >>If you have already tested it I would like to take your point. > >>If I got your point right then, > >> > >>1. Authentication server generates Session Secret, but not > >>Session Key, > >> and sends it to both supplicant and AP.
I missed this in my previous mail. The supplicant already has the session secret (since it's generated by the AS and supplicant together) so it is only sent to the AP. Having the AS send the keying material to both the AP and STA would defeat the whole purpose of the key distribution mechanism (which is to distribute session keys without a previously shared secret). > >>2. AP generates both Session(Unicast) Key and Broadcast Key > >>and encrypts > >> them using Session Secret and sends to the supplicant. The broadcast key is most probably previously generated, but otherwise this the behavior we've seen. > >>3. Supplicant decrypts Session(Unicast) Key and Broadcast key > >>using the > >> Session Secret that it got from Authentication Server. using the session secret that was derived as part of the TLS authentication. > >>Please correct me if I am wrong. > >>I would appreciate if you can send some links/documents > >>confirming this. > >> > > > >Section 4 of the "IEEE 802.1X RADIUS Usage Guidelines" I-D > ><URL:http://www.ietf.org/internet-drafts/draft-congdon-radius > -8021x-20.txt> > >combined with section 3.5 of rfc 2716 should cover most of it. > > > Thankyou for the link. > The draft has no reference about the above 3 step sequence. > If possible, can you send more links/documents in this regard. Sorry, AFAIK there are no document that officially spells out all the details; the IEEE 802.1x standard, RFC 2716 and the I-D mentioned above together is probably the best documentation available on this. > >>I was on vacation last month and I might have missed many mails. > >>I just got your patch from the archives. > >> > >>Your patch looks good to me except for use of VSA (MS-MPPE-...). > >>I am still not sure, if the supplicant is linux based and > >>cisco AP is used, > >>What Radius attributes should be used for these key sharing? > >> > > > >Which Radius attributes are used to send the keying data to > >the AP doesn't matter to the supplicant since it only sees > >the EAPOL-Key messages over 802.11. We didn't test with the > >Xsupplicant (we may do that when we get time, but don't hold > >your breath) but the code seems to work like the described > >behavior. > > > >Cisco APs use the same Radius attributes (it'd be pretty weird > >if they didn't). We did not test that with freeradius EAP-TLS, > >but we did trace the communication between a Cisco AP and Win2k > >radius during an EAP-TLS authentication. > > > > I am not sure I made my point clear. > Cisco AP & linux supplicant are just an example to refer to non MS. > To pass 802.11 EAPOL key messages from RADIUS Server > to AP to suppliant (no matter, which RADIUS Server, AP and > Supplicant are used) they need to support Microsoft dictionary. > As they use MS-MPPE-.. VSAs. This is weird. The EAPOL-Key messages originates from the AP not the authentication server. I'll try to make it a bit more clear (note that the below is based mostly on observed behavior of existing implementations). 1. trust by v----- shared radius key ---v STA AP AS (radius) ^ ^ |STA --------- 2. EAP/TLS authentication --------------AS| derives shared secret for distribution of WEP keys based on TLS master secret ^ ^ |AP - 3. WEP key ---------AS| distribution secret sent to AP using MS-MPPE-... VSAs ^ ^ |STA 4. WEP keys sent in ---AP| EAPOL Key frames encrypted using the key distribution secret The three key (no pun intended) observations I make from the above are: 1. the trust beetwen the STA and AP is derived from the trust between STA/AS and AP/AS - this is not a good thing 2. the mechanism used to send the key distribution secret from AS to AP is of no interest to the STA, currently this is done using MS-MPPE-{Send|Recv}-Key but that could (should?) be changed 3. the AS is not involved in the generation of the EAPOL-Key messages (and hence the WEP keys), this is all done by the AP > Unfortunately "IEEE 802.1X RADIUS Usage Guidelines" also talks > about the use of these MS-MPPE-... VSAs. The use of the MS-MPPE- VSAs are probably an artifact of Microsoft being the first to use EAP-TLS as an 802.11/1x authentication mechanism. > I expect something like IEEE802 dictionary and if the APs claim to > support 802.11 EAPOL key messages, then it is understood that > one of the VSAs from this IEEE802 dictionary are used. > > I hope you got my point. > > What is your opinion on the following snip from > "IEEE 802.1X RADIUS Usage Guidelines" > > <snip> > > 5.7. Key management issues > > The EAPOL-Key descriptor described in Section 4 is likely to be > deprecated in the future, when the 802.11 enhanced security group > completes its work. Known security issues include: > > <snip> That's Task Group I of 802.11. They are discussing a number of rather large changes to 802.11/WEP including migrating WEP from RC4 to AES, a better MIC, improved per-packet WEP-key generation. Check out their document submission queue at <URL:http://grouper.ieee.org/groups/802/11/> for more information (if you've not already done that). EAPOL-Key messages may or may not become deprecated (I haven't seen any indications of the latter, but I don't have access to TgI internal documents/discussions) however that is a non-issue for the Authentication Server since the EAPOL-Key messages are exchanged from AP to STA. Best regards, Henrik - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
