summaryrefslogtreecommitdiffstats
path: root/raddb/mods-available/wimax
blob: 3add59e52921e5192c1d422d5f1a6aae87493b17 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
#
#	The WiMAX module currently takes no configuration.
#
#	## Instructions for v1 and v2.0 WiMAX
#
#	It should be listed in the "authorize" and "preacct" sections.
#	This enables the module to fix the horrible binary version
#	of Calling-Station-Id to the normal format, as specified in
#	RFC 3580, Section 3.21.
#
#	In order to calculate the various WiMAX keys, the module should
#	be listed in the "post-auth" section.  If EAP authentication
#	has been used, AND the EAP method derives MSK and EMSK, then
#	the various WiMAX keys can be calculated.
#
#	Some useful things to remember:
#
#	WiMAX-MSK = EAP MSK, but is 64 octets.
#
#	MIP-RK-1 = HMAC-SHA256(ESMK, "miprk@wimaxforum.org" | 0x00020001)
#	MIP-RK-2 = HMAC-SHA256(ESMK, MIP-RK-1 | "miprk@wimaxforum.org" | 0x00020002)
#	MIP-RK = MIP-RK-1 | MIP-RK-2
#
#	MIP-SPI = first 4 octets of HMAC-SHA256(MIP-RK, "SPI CMIP PMIP")
#		plus some magic... you've got to track *all* MIP-SPI's
#		on your system!
#
#	SPI-CMIP4 = MIP-SPI
#	SPI-PMIP4 = MIP-SPI + 1
#	SPI-CMIP6 = MIP-SPI + 2
#
#	MN-NAI is the Mobile node NAI.  You have to create it, and put
#	it into the request or reply as something like:
#
#		WiMAX-MN-NAI = "%{User-Name}"
#
#	You will also have to have the appropriate IP address (v4 or v6)
#	in order to calculate the keys below.
#
#	Lifetimes are derived from Session-Timeout.  It needs to be set
#	to some useful number.
#
#	The hash function below H() is HMAC-SHA1.
#
#
#	MN-HA-CMIP4 = H(MIP-RK, "CMIP4 MN HA" | HA-IPv4 | MN-NAI)
#
#		Where HA-IPv4 is	WiMAX-hHA-IP-MIP4
#		or maybe		WiMAX-vHA-IP-MIP4
#
#		Which goes into		WiMAX-MN-hHA-MIP4-Key
#		or maybe		WiMAX-RRQ-MN-HA-Key
#		or maybe even		WiMAX-vHA-MIP4-Key
#
#	The corresponding SPI is SPI-CMIP4, which is MIP-SPI,
#
#		which goes into		WiMAX-MN-hHA-MIP4-SPI
#		or maybe		WiMAX-RRQ-MN-HA-SPI
#		or even			WiMAX-MN-vHA-MIP4-SPI
#
#	MN-HA-PMIP4 = H(MIP-RK, "PMIP4 MN HA" | HA-IPv4 | MN-NAI)
#	MN-HA-CMIP6 = H(MIP-RK, "CMIP6 MN HA" | HA-IPv6 | MN-NAI)
#
#		both with similar comments to above for MN-HA-CMIP4.
#
#	In order to tell which one to use (CMIP4, PMIP4, or CMIP6),
#	you have to set WiMAX-IP-Technology in the reply to one of
#	the appropriate values.
#
#
#	FA-RK = H(MIP-RK, "FA-RK")
#
#	MN-FA = H(FA-RK, "MN FA" | FA-IP | MN-NAI)
#
#		Where does the FA-IP come from?  No idea...
#
#
#	The next two keys (HA-RK and FA-HA) are not generated
#	for every authentication request, but only on demand.
#
#	HA-RK = 160-bit random number assigned by the AAA server
#		to a specific HA.
#
#	FA-HA = H(HA-RK, "FA-HA" | HA-IPv4 | FA-CoAv4 | SPI)
#
#		where HA-IPv4 is as above.
#		and FA-CoAv4 address of the FA as seen by the HA
#		and SPI is the relevant SPI for the HA-RK.
#
#	DHCP-RK = 160-bit random number assigned by the AAA server
#		  to a specific DHCP server.  vDHCP-RK is the same
#		  thing.
#
#
#
#	## Instructions for v2.1 (LTE) WiMAX:
#
#	When called from the "authorize" this module will detect the
#	presence of the following attributes:
#
#		request:WiMAX-Re-synchronization-Info
#		control:WiMAX-SIM-Ki
#		control:WiMAX-SIM-OPc
#
#	If all attributes are present, (i.e. a known SIM is requesting a
#	resync) then the module will attempt to extract the new SQN and
#	save it in control:WiMAX-SIM-SQN. It will also save a copy of
#	RAND from the request in control:WiMAX-SIM-RAND.
#
#	The resulting value of SQN can then be saved in a database
#	e.g. via a call to the sql module using some unlang
#
#	When called in the "post_auth" section it looks for:
#
#		control:WiMAX-SIM-Ki
#		control:WiMAX-SIM-OPc
#		control:WiMAX-SIM-AMF
#		control:WiMAX-SIM-SQN
#		request:WiMAX-Visited-PLMN-ID
#
#	If all these are present then it will attempt to generate the
#	keys for EPS AKA.
#
#	First it checks for the presence of control:WiMAX-SIM-RAND and
#	if it is not present it generates a new RAND value which is
#	stored in reply:WiMAX-E-UTRAN-Vector-RAND. If it is present then
#	the value is simply copied to the reply attribute.
#
#	Then it calls the Milenage algorithm to generate:
#
#		reply:WiMAX-E-UTRAN-Vector-XRES
#		reply:WiMAX-E-UTRAN-Vector-AUTN
#
#	And finally generates KASME which is stored in:
#		reply:WiMAX-E-UTRAN-Vector-KASME
#
#
#	NOTE: It is up to the system administrator to make sure that all
#	the necessary "control" attributes are populated with the
#	required values. The IMSI is likely to be found in User-Name in
#	the request and this can be used as the key to grab the values
#	from a database.
#
#
wimax {
	#
	#  Some WiMAX equipment requires that the MS-MPPE-*-Key
	#  attributes are sent in the Access-Accept, in addition to
	#  the WiMAX-MSK attribute.
	#
	#  Other WiMAX equipment request that the MS-MPPE-*-Key
	#  attributes are NOT sent in the Access-Accept.
	#
	#  By default, the EAP modules sends MS-MPPE-*-Key attributes.
	#  The default virtual server (raddb/sites-available/default)
	#  contains examples of adding the WiMAX-MSK.
	#
	#  This configuration option makes the WiMAX module delete
	#  the MS-MPPE-*-Key attributes.  The default is to leave
	#  them in place.
	#
	#  If the keys are deleted (by setting this to "yes"), then
	#  the WiMAX-MSK attribute is automatically added to the reply.
	delete_mppe_keys = no
}