Hi,

I recently attended the Moonshot workshop last week at Surfnet and I
still have a couple of questions. Some were already (partially)
answered, though I was asked to address them on this mailing list, so
here goes.
  ______                                    ____
 |      |                                  |    |
 |______| client                           |    | IdP
 /     /                                   |o   |
/_____/                 (implicit trust)   |____|
   |   GSS+EAP              PSK TLS+GSS   /    |
   |                       ______________/     | GSS (1/2 DH + IP)
   |                      /   EAP              |
 __|                  ___/                    _|______________
|   | RP (SSH)       |   | RP proxy          |                |
|   |                |   |                   |  TRUST ROUTER  |
|o  |________________|o  |___________________|     NETWORK    |
|___|   RADSEC       |___| GSS (1/2 DH + IP) |________________|
        + EAP

I have remarks/questions regarding:

1. Client <-> IdP trust relationship
2. Password in store keyring
3. RP proxy <-> RP trust relationship
4. RP proxy/IdP <-> TRN trust relationship
5. RP proxy <-> IdP trust relationship
6. Rekeying and Perfect Forward Secrecy
7. IP support in TIDS/TIDC
8. User mapping in RP

1. Client <-> IdP trust relationship
Right now there is a moonshot identity selector. This allows for
supplying usernames and passwords without a trust anchor. This should
*never* be allowed. Any malicious RP implementing GSS+EAP can grab hold
of the password. In the XML there is a possibility to set a fingerprint,
but this is not mandatory.

It should be mandatory to set a trust anchor. Our RADIUS infrastructure
gets a fresh certificate annually, so basing this on a fingerprint will
fail annually. This should use a CA + Subject checking like in the
eduroam world. A user can be expected to specify it wants to use the
system CA store or a specific CA and authenticate to
"moonshot.nikhef.nl". Not specifying this should result in not being
able to authenticate.

2. Password in store keyring
Right now the identity selector allows to store the institute
credentials in the keyring. Can this be disabled on a policy basis? It's
okay if it keeps the password in mlocked memory as an ssh/gpg agent
would do it, but in the keyring is asking for trouble. A user can be
asked to enter his/her password once every 24 hours.

3. RP proxy <-> RP trust relationship
In the moonshot workshop, following the Wiki, we had to create
certificates on the RP Proxy, with a free form text string CN. Can this
be configured to use subject to hostname checking for client and server
certificates?

4. RP proxy/IdP <-> TRN trust relationship
In the XML there is a trust anchor configured based on fingerprint,
client authentication is done based on a username/password. This does
not allow to replace the TRN certificates and makes me wonder why
certificates are used in the first place instead of keys. If the
certificate expires, the entire federation goes down. Is the
subject/expiration date on the certificate still verified?

5. RP proxy <-> IdP trust relationship
This trust relationship and key material depend entirely on the online
benevolent behaviour of the Trust router. A Diffie-Hellman key exchange
is used over the trust router to agree on a PSK and the RP proxy will
happily connect to any IP specified by the Trust Router Network with the
key it just agreed on using Diffie-Hellman. There is no trust
verification between IdP and RP proxy. This means that the Trust Router
Network can perform a Man-in-the-Middle attack on the entire federation
and is a 100% fully trusted component that can attack the entire
federation trust. There is also no infrastructure for verifying signed
SAML statements coming from the IdP. It seems to me that the trust
router may be better replaced with a signed list of realm <-> hostname
mapping per community and let DNS + PKI fix this trust problem. The
added benefit would be that the hostname of the IdP has to end with the
realm (so only .nikhef.nl servers for @nikhef.nl). It also would allow
to check that the client will authenticatie to 'moonshot.nikhef.nl' so
the RP proxy will only connect to that one. Another added benefit is
that ciphers like ECDHE-RSA-AES256-GCM-SHA384 can be used which provide
Perfect Forward Secrecy. Or am I overlooking something?

6. Rekeying and Perfect Forward Secrecy
The wiki states that the key material should be in /var/tmp in a sqlite
keys file with 777 world writable permissions(!!). Any reboot of the
IdP/RP proxy will wipe this database and any previously agreed upon keys
are wiped from the store, causing the IdP/RP proxy to go offline. There
does not seem to be a rekeying mechanism. How will the PSKs be rekeyed
and how often will this happen?

7. IP support in TIDS/TIDC
The wiki requested me to specify an IP address when manually starting
the TIDS service. Naturally, since it didn't say legacy IP, I assume the
current version of IP and use my IPv6 address. This leads to messages
about inet_aton() not working. This seems to be a bug.

8. User mapping in RP
Right now, as I understand it, there is no mechanism for mapping users
to semi-permanent or pool accounts at the RP side (at least for SSH).
Nikhef may be able to help with this, as the grid world already has
several solutions for this.

Looking forward to your input.

Regards,

Wilco Baan Hofman