You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

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. General structure

An attempt was made to translate the XSD min- and maxOccurs to regex-like quantifiers.
No quantifiers means it needs to be present (once).
+ = (1 - unbound)
* = (0 - unbound)
? = (0 - 1).

EAPIdentityProviderList
  EAPIdentityProvider+ (version, lang, ID)
    ValidUntil?

    AuthenticationMethods+
      AuthenticationMethod*
        EAPMethod?
          Type
          TypeSpecific
          VendorSpecific
        ServerSideCredential?
          CA*
          ServerID*
        ClientSideCredential
          OuterIdentity?
          InnerIdentityPrefix?
          InnerIdentitySuffix?
          InnerIdentityHint?
          Username?
          UserName?
          Password?
          ClientCertificate?
          IntermediateCACertificate*
          Passphrase?
          PAC?
          ProvisionPAC?
        InnerAuthenticationMethod
          EAPMethod?
          NonEapMethod?
            Type
            TypeSpecific?
            VendorSpecific*
          ServerSideCredential?
          ClientSideCredential?

    CredentialApplicability
      IEEE80211*
        SSID?
        ConsortiumOID?
        MinRSNProto?
      IEEE8023*
        NetworkID

    ProviderInfo?
      DisplayName*
      Description*
      ProviderLocation*
        Longitude
        Latitude
      ProviderLogo (mime, encoding)
      TermsOfUse*
      Helpdesk?
        EmailAddress*
        WebAddress*
        Phone*

    VendorSpecific?

ClientCredential and ServerCredential

Not all EAP types and non-EAP authentication methods need or support all types of credentials in the list below.
While the Schema allows to put all kinds of credential information inside every AuthenticationMethod, even where the information is not applicable, tags which are not applicable for an authentication EAP or non-EAP type SHOULD NOT be included in the corresponding instance of AuthenticationMethod or InnerAuthenticationMethod when producing the XML file, and MUST be ignored by the entity consuming the XML file if present in the XML file.

IEEE80211

The conditions inside this element are considered AND conditions. It does e.g. not make sense to have multiple SSIDs in one IEEE80211 field because the condition would never match.
To specify multiple ORed network properties, use multiple IEEE80211 instances.

EAPIdentityProvider

If the optional attribute "lang" for the EAPIdentityProvider tag is specified, then all user-displayable strings inside this tag are to be considered suitable for use in user interfaces in that language. Individual lang tags for the sub-tags inside EAPIdentityProvider then SHOULD NOT be used.

If the optional attribute "lang" for the EAPIdentityProvider tag is not set, individual sub-tags which contain user-displayable strings SHOULD be marked with the language they are written/available in.

InnerIdentity

The EAP metadatafile can contain extra information about the InnerIdentity, mostly used to streamline domain specific form elements:

  • InnerIdentityPrefix contains the required domain prefix if any. E.g. DOMAIN/
  • InnerIdentitySuffix contains the required domain suffix, if any. E.g. @DOMAIN
  • InnerIdentityHint is a boolean, telling the app to populate the InnerIdentity field using the InnerIdentityPrefix or Suffix and placing the cursur a the correct place (after the / if prefix is used or before the @ in the case of suffix).

ClientCertificate


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 TLS then a client certificate (PKCS12) MUST be provided If the client cannot read this certificate due to encryption, a passphrase MUST be used to decrypt the container.


  • No labels