An open discussion list for topics related to the eduGAIN interfederation service.

[Guy Halse <guy AT tenet.ac.za>]

    Hi

On 2021/04/06 16:23, Peter Schober wrote:

There is no know established/documented process that would allow an
Azure AD "tenant" to demonstrate ownership (or the right to use) of an
entityID of the form "https://sts.windows.net/<UUID>/", leading to the
problem of potential IDP impersonation within eduGAIN.

On 2021/04/06 20:28, Thijs Kinkhorst wrote:

    But even
      then, we do also always require scopes to be set, which _are_
      validated via whois to be owned by the registring institution.
    
    
    I'm going to pick up a little further on this...
    
    In a post GDPR world there's no easy way to demonstrate ownership of
    of a domain either, at least not under the ICANN temporary
    specification for gTLD data[1]. A lot of federations have the
    benefit of being the DNS registry for their academic second level
    domain, or having a back door into their national DNS registry.
    However, if an entity chose to use an entityID that was rooted in
    the DNS space but that used one of the new gTLDs or otherwise
    out-of-balliwick from a federation's "home" regististry, there's
    potentially no way whatsoever of proving ownership via WHOIS or any
    other publicly accessible information.
    
    Thus I think the concept of proving "ownership" or even "right to
    use" is dated. It is also one that other bodies, such as the CA/B
    Forum, have moved away from. What matters more these days is
    demonstrating operational control. That's the model used by Azure to
    prove right to use for a domain[2], and is the same model used by
    Google Workspace[3]. It is also the model used by most public
    certification authorities (think LetsEncrypt[4]) as provided for in
    the CA/B Forum baseline[5].
    
    I guess the idea here is that if I can demonstrate operational
    control, I have an implicit right to use.
    
    We've already got several good models for demonstrating operational
    control of the DNS, and I've long realised at some point I'm going
    to have to use one of them to validate a scope in metadata (I'm
    still waiting for someone to add a .africa gTLD scope; maybe I
    should add one of the ones we own).
    
    What I don't have yet is a good model for demonstrating operational
    control of an AzureAD entityID. However, like Thijs, I'm not
    actually convinced it is completely necessary if our mechanisms for
    validating organisational contacts are robust enough. Nevertheless,
    I can think of some hackish ways it could be be done -- and we used
    one such mechanism for the AzureAD tenant we did take on to cover
    the spirit, if not the letter, of our MRPS.
    
    I've wanted to rewrite the domain validation portion our MRPS to
    cater for this new world for some time. If anyone's interested in
    collaboratively working on some template wording, I'd be keen to be
    involved.
    
    - Guy
    
    [1]
    https://www.icann.org/resources/pages/gtld-registration-data-specs-en
    [2]
https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/add-custom-domain
    [3] https://support.google.com/a/answer/60216
    [4] https://letsencrypt.org/docs/challenge-types/
    [5] 3.2.2.4 of
    https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.4.pdf

--
Guy Halse
Executive Officer: Trust & Identity Tertiary Education & Research Network of South Africa NPC Fault Reporting: +27(21)763-7147 or support AT tenet.ac.za
Office: +27(21)763-7102
http://www.tenet.ac.za/contact
https://orcid.org/0000-0002-9388-8592

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature