1.0. Introduction
The EAP metadata is returned as an XML. Clients MAY validate this metadata according to the XSD specification. If the validation matches, client can then parse it using an XML parser.
Note: This EAP XSD is modified from the CAT project at https://github.com/GEANT/CAT/blob/master/devices/xml/eap-metadata.xsd
1.1. Methods and authentication
The EAP metadata will have different methods and inner authentication methods defined. Below is a list that can be present in the eap file:
Methods (<EAPMethod><Type>...</Type></EAPMethod>)
- 13: TLS
- 21: TTLS
- 25: PEAP
Inner authentication type (<InnerAuthenticationMethod><EAPMethod><Type>...</Type></EAPMethod></InnerAuthenticationMethod>)
- 0: None
- 1: PAP
- 2: MSCHAP
- 3: MSCHAPv2
- 25: EAP_PEAP_MSCHAPv2
- 26: EAP_MSCHAPV2
Based on these authentication methods, there are various "flows" we can have to continue connecting. We will discuss these in the next sections
1.2. Needs login credentials
The first possibility is that the user needs to provide login credentials. This is the case where the authentication method IS NOT TLS (meaning method code IS NOT 13) and where the client has not gotten previous credentials before.
The user then needs to input his username (including the @realm) and password in the UI. If there is a possibility that this can be automatically configured within the OS UI then this MUST be preferred.
1.3. Needs client certificate
If the authentication method is NOT TLS then a client certificate (PKCS12) MUST be provided by the user. If the client cannot read this certificate due to encryption, a passphrase MUST be provided by the user.