>>>>> "Jim" == Jim Schaad <[log in to unmask]> writes:


There are no sessions using gss-eap and TLS.

There are certificates in one place in the system.
EAP-TTLS to TR-IDP and IDP use certs known by user.

    Jim> 1.  User opens TLS/TCP:XXX session to RP-Service and start
    Jim> running GSS-EAP - User name="@example.org"

OK, actually I guess that one could be TLS + GSS.
    Jim> 6.  RP-AAA-TR opens TLS/TCP:666 session to TR (anonymous) then
    Jim> starts Moonshot w/ username="[log in to unmask]"

First, this is using gss_wrap rather than TLS.
Second this is over the temporary identity port; recall that TR uses two
ports (12308 and 12309)


    Jim> 9.  TR determines that it needs to route the Trust Message to
    Jim> IDP - however it does not have a relationship now.  The trust
    Jim> network has the name of the IdP pre-configured in TR's
    Jim> database.

It has a relationship but not a connection

    Jim> 10.  TR opens a TLS/TCP:666 session to IDP-TR and sends an
    Jim> GSS-EAP request to the server.

This is also over the temporary identity port and is simply gss not
tls/gss.

    Jim> 11.  IDP-TR has no current path back to TR-IDP and thus cannot
    Jim> do the validation.  At this point there are two options in the
    Jim> protocol.  The first would be to open a separate TCP session

No. IDP-TR is a gss acceptor.
GSS acceptors cannot act as temporary identity clients.

All Moonshot acceptors can do is talk to a AAA proxy.

IDP-AAA-TR is really two things
IDP-AAA-TIS and IDP-AAA-TIC.
(temporary identity server and client)
TR talks to IDP-AAA-TIS.
IDP-AAA-TIS talks to some RADIUS server probably IDP-AAA as an RP.
IDP-AAA talks to IDP-AAA-TIC to get a key for TR-IDP.

so it really doesn't make sense to reverse the flow and re-use the
connection to TR.
Also, in the more than one TR in the world model, it's not at all clear
that the incoming TR is required to be the TR that IDP-AAA-TIC will
choose to use.
It's probable because IDP-AAA-TIS probably has a short ACL.

--Sam