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