Hi.

I don't think I've been sufficiently clear about the use case for the
alternate security mechanism (ASM) and how I think that differs from
MTP.  In fact, in writing this message, I've realized that the
justification for ASM in my head was not consistent with its
capabilities.  So, I'll go through, discuss what I think ASM is about,
discuss some alternatives, and discuss what I think we'd need to do to
ASM in order to meet the goal I think it has. I definitely do not think
MTP is an alternative to ASM.


So, let's consider ASM.  We're proposing to use AAA environments for
authentication and SAML for authorization and personalization.
Basically what we're saying here is that by providing flexible naming of
attributes, a query protocol, facilities for managing privacy,we believe
that SAML provides value even if you're not using it today.

Examples of things we've done that push us down this path include
talking about extracting home directory information from SAML for ssh.
An alternative strategy we could have adopted would be to say that if
you're using SAML we'll support an assertion, but since RADIUS has an
attribute exchange mechanism we'll use that for attributes we define
within the Moonshot context.  Under this alternative , for any new
applications we moonshoot and for which we only expect to be used via
Moonshot, we would expect to define RADIUS attributes.


Sometimes we cannot just include the SAML attribute assertion in RADIUS,
mostly for MTU reasons. Even if we could, see IDP metadata
below. 

ASM comes about because we do not want to force people to deploy
multiple security infrastructures. My view is that ASM should give
people as much functionality with our use of SAML as if we'd used RADIUS
for attributes without requiring them to deploy security mechanisms
above what they need to deploy on top of AAA. They're probably going to
have to deploy additional software, although in principle that could be
part of their AAA server. We don't want to force them to go through
additional enrollments, registrations, key managements, or maintenance
of additional naming just to get basic Moonshot authorization and
personalization.

So, ASM should bootstrap SAML communication given AAA communication and
naming.  I think that means it needs to establish RP metadata at the
IDP, IDP metadata at the RP andcredentials between both.  This is a
change: when we'd first talked about ASM, we were thinking basically
only in terms of credentials.  That mostly is because I didn't
understand all the metadata implications at the time.

So, why do I think MTP is not an alternative?  The main reason is that
MTP requires additional infrastructure on top of the AAA
infrastructure. In particular, a metadata authority is required. Some
entity trusted by the SP needs to understand SAML naming enough to
validate the IDP's metadata. Similarly, the IDP needs someone to
validate the SP's metadata.

This creates a significant new requirement on the AAA core. It's a
requirement that JANET(UK) would not have trouble meeting, but I think
it limits the authorization and personalization aspects of Moonshot
significantly. Also, I think it significantly decreases the incremental
deployability of Moonshot in some contexts: to connect two Moonshot
cliques into a connect graph, you need to get SAML metadata connectivity
as well as AAA connectivity.

Also, remember that MTP and KMP are optional extra infrastructure
requiring multiple endpoints.

It might be possible to do something that looked a lot closer to MTP
than the existing ASM. However there are some significant
differences. MTP assumes that the metadata consumer has an EAP
credential. ASM cannot assume either the IDP or the SP has an EAP
credential. As mentioned previously MTP assumes functionality out of the
AAA core (and really explicitly assumes the existence of such a core.)

So, I think we have a couple of options.  We can have something that
fills the role of ASM, possibly not based on ASM. Alternatively, we can
change the scope of how we use SAML.  I cannot think of other
alternatives that do not create a significant divide between the
functionality you get when you do and do not have SAML connectivity.