Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

To protect against rollback attacks, it is good practice to check the client MUST check if the sequence number if it has updated.

Where instances is a list of the form:

...

If there are multiple profiles then multiple profiles MUST be shown in the UI, asking for a selection to the user. The profile indicated with the default attribute set to true SHOULD be in bold, or in case the UI does not support bold text, it SHOULD have a "*/" OR "(default)" pre/postfix.

When the profile has been selected, we can use the correct flow to get the EAP metadata. In the next section, we will go over implementing the various flows.

...

If the value is not a URL, or the scheme is not HTTP/HTTPS, the app MUST NOT open the url URL in the browser but should show a friendly error in the UI that the profile is not available.

...

If the 401 is returned, or the client did not even have the a non-expired access token in the first place the whole OAuth procedure MUST be redone.

EAP metadata

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

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
  • PAP: 1
  • MSCHAP: 2
  • MSCHAPv2: 3
  • EAP_PEAP_MSCHAPv2: 25
  • EAP_MSCHAPV2: 26


Based on these authentication methods, there are various "flows" we can have to continue connecting. We will discuss these in the next sections

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 (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.

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.