Security

Reply
Highlighted
All-Decade MVP 2020

Re: Correctly configure EAP PEAP Windows client

 

The RADIUS server returning the inner identity (with PEAP at least, in the last packet after EAPOL is over) is not an issue.  It never gets past the NAS so it never appears anywhere but in admin interfaces, so there is no false sense of securty.  I wouldn't advise using identity protection if your RADIUS server could NOT do so, as tcapalli notes, but really the outer identity should never be trusted and should be treated as trash data you never look at, except when you are doing federated realm auths.

 

 

Highlighted
Guru Elite

Re: Correctly configure EAP PEAP Windows client

bjulin,

 

So just to spell it out for the end user or administrator of these supplicants, when should identity privacy be used and why?


*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.5 User Guide
InstantOS 8.5 User Guide
Airheads Knowledgebase
Airheads Video Knowledge Base
Remote Access Point Solution Guide
ArubaOS Consolidated Release Notes
ArubaOS 8 ViA VPN Solution Guide

View solution in original post

Highlighted
All-Decade MVP 2020

Re: Correctly configure EAP PEAP Windows client

 

Well first let's say exactly what it does.

 

When you check this box, you can type in a username, which is a junk username, so let's say we entered "anon".

Then, it takes the value of the username you enter when you log in (or have saved in the profile) and chops off everything before the

'@' in that username, and puts the contents of the textbox there instead.  So if you log in as me@realm.com, it will replace

that with anon@realm.com.

 

So first rule: ONLY use this when your username is of the form username@realm.domain.  (On other operating systems, where

this is usually called the "anonymous identity" this restriction does not apply and you can set the entire value of the anonymous

identity independently from the username.  The above behavior is a microsoft-only constraint.)

 

So at this point anon@realm.com is used as the username in the EAPOL conversation across the open-system WiFi layer.

If someone is sniffing packets, either on wireless or sniffing RADIUS packets on the other side of the NAS, this is what they will

see.  Your actual username (me@realm.com) is only used inside encrypted tunnels.

 

So second rule: If you do not care that any random individual can collect a list of your usernames and their MAC addresses, don't

bother with this option.  If you do care, or are sending naked RADIUS across the Internet without RADSEC, you may want to consider using it.

 

Now, whether or not you use this option you should NEVER use the anonymous identity for any sort of identification, policy decision,

or purpose with one exception: you can use the part after the '@' sign it to route a non-home realm user in a federation like eduroam to

his home AAA server so that you can ask that AAA server if his username and password is valid and if he should be allowed access

to your network based on an agreement between you and that other organzation.

 

Say for example, you had a rule saying any user named "bob" was allowed to log into a server.  Anyone can put "bob" in the

anonymous identity instead of "anon."  So never listen to what is in the anonymous identity.  Make all your user-based policy decisions using only usernames from inside the encrypted tunnel.  Likewise, if you controllers use the anonymous identity to display users in

the UI, this person will show up when you search for bob, even if their real username is nancy.

 

For this reason a lot of RADIUS servers will take the username from inside  the encrypted tunnel and send it back to the controllers in the last RADIUS packet.  When using PEAP, the last RADIUS packet is simply eaten by the NAS, so this is safe to do if your RADIUS

communications are secure -- it is never copied over into an EAPOL frame and sent over the air.

 

Rule #3: if you do not send inner identities back to your NAS, you probably do not want to use this option, because all your users in the contoller UI would be named "anon@realm.com"  However, you should be aware that anyone that can perform a dot1x auth can fool your NAS into displaying whatever they want as their username.  You probably do not want that to happen and might want to rethink your design.

 

Now just as a side-note, let's look back at the federated authentication (where you route to another organization's AAA server).  If you do this, you have to rely on that AAA server to give you some sort of meaningful identifier for the user (preferred way is called a CUI, chargeable user identity) and this will be returned in at least the last RADIUS packet, if that insitution has set things up correctly.  Since the client talks encrypted with their home server, you have no idea what their username is.  Some home servers may send you back a meaningful outer username but you cannot rely on that either.  You have to take the parts you have (CUI, the original realm you routed to, the MAC address, and home server's operator name from the home server's last packet) and do the best you can to display something useful in the NAS.  You don't always have it, but prefrably you would want some digits of the CUID and the home realm to appear in your NAS, so you could file a complaint about misbehavior with the owner of the home server and they would know who's behavior you are complaining about, because they kept track of what CUIs they sent you for who.

 

 

Highlighted
Contributor I

Re: Correctly configure EAP PEAP Windows client

We have an issue with the 'connect to these servers' option as we run eduroam which is a federated system. Adding our homesite radius servers in here would mean the user would not be able to authenticate at other institutions running eduroam.

 

Highlighted
MVP Expert

Re: Correctly configure EAP PEAP Windows client

Yes,It is a windows feature which allow user to connect only to trusted  authentication servers which are added in 'connect to these servers' option, we can add mulitple authentication servers details, enter the domain(s) separating each server name with a semicolon. For example, server.domain1.com; server.domain2.com.

 

 

 

 


Pavan Arshewar | ACCP

If my post address your queries, give kudos and accept as solution!
NOTE: Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba or Hewlett Packard Enterprise.
Highlighted
Contributor I

Re: Correctly configure EAP PEAP Windows client

Yes

 

Highlighted
Moderator

Re: Correctly configure EAP PEAP Windows client

No, that’s not how it works. You only need to trust your home EAP server.


If this response is more than 1 year old, it may no longer be accurate. Please consult official Aruba documentation, TAC or your Aruba SE.

| Aruba Alumni | @timcappalli | timcappalli.me |

Highlighted
Contributor I

Re: Correctly configure EAP PEAP Windows client

ah, thats good to know. A misunderstanding on my part.

 

So if i'm at my homesite and it uses  myradiusserver.auth.com which is in my WLAN profile and i travel to another site which sends my request to foreignradius.othersite.com which then sends to the orps and back to my homesite radius the client will see it as my homesite radius?

Highlighted
Moderator

Re: Correctly configure EAP PEAP Windows client

The request is proxied to your home university where EAP termination occurs. The certificate is from the terminating EAP server.


If this response is more than 1 year old, it may no longer be accurate. Please consult official Aruba documentation, TAC or your Aruba SE.

| Aruba Alumni | @timcappalli | timcappalli.me |

Highlighted
Contributor I

Re: Correctly configure EAP PEAP Windows client

Thanks. Thats very helpful.

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: