Page History

...

Note: This EAP XSD is modified from the CAT project at https://github.com/GEANT/CAT/blob/master/devices/xml/eap-metadata.xsd

EAP metadata RFC (draft): https://www.ietf.org/archive/id/draft-winter-opsawg-eap-metadata-02.txt

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, tags 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.

...

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

If the optional attribute "lang" for the EAPIdentityProvider tag element is not set, individual sub-tags 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.

ProviderInfo

The 'ProviderInfo' container allows to specify a range of potentially useful information for display to the user (some of which is relevant only during installation time, other pieces of information could be retained by the EAP peer implementation and displayed e.g. in case of failed authentication).

If more authoritative information about the issuer is available (e.g. if the file is signed with S/MIME and carries an Organisation name (O attribute) in the signing certificate) then the more authoritative information should be displayed with more prominence than the self-asserted one.

1.1.  Methods and authentication

...

Based on these authentication methods, there are various "flows" we can have 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 is NOT TLS (meaning method code IS is NOT 13) and where the client has not gotten received previous credentials before.

The user then needs to input his her username (including the @realm@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.

...

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