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

Compare with Current View Page History

« Previous Version 11 Current »

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* (format, encoding)
          ServerID*
        ClientSideCredential
          OuterIdentity?
          InnerIdentityPrefix?
          InnerIdentitySuffix?
          InnerIdentityHint?
          Username?
          UserName?
          Password?
          ClientCertificate? (format, encoding)
          IntermediateCACertificate* (format, encoding)
          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, elements 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 element is specified, then all user-displayable strings inside this element are to be considered suitable for use in user interfaces in that language. Individual lang attributes for the child elements inside EAPIdentityProvider then SHOULD NOT be used.

If the optional attribute lang for the EAPIdentityProvider element is not set, individual child elements 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 the realm specific InnerIdentity form element:

  • InnerIdentityPrefix contains the required realm prefix if any. E.g. DOMAIN/
  • InnerIdentitySuffix contains the required realm 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).

Certificates

ServerSideCredential contains a list of CA's that should contain valid CA certificates.

ClientSideCredential contains the client certificate, optionally protected by a passphrase.

Certificates have a format and encoding attribute. The format should be X.509 and encoding base64.

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" possible 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 received previous credentials before.

The user then needs to input her 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 ciphertext.


  • No labels