Trust argument for Rserpool

I'm writing up the trust argument for Rserpool and I have come across an
issue.  It involves inadvertently mixing secure and unsecured modes of
Rserpool.  We have said in the spec that this is disallowed, but I'm not
sure that there is any feature for indicating to a PU, PE or ENRP server
the proper security mode.

For example, if I'm a secure ENRP server and a PE tries to register
without using TLS, then I'm supposed to reject the registration.  We
need some response code to indicate that registration failed due to lack
of security so the PE knows it has the option of trying again with TLS.

Likewise if ENRP servers try to exchange data and one is secure and one
not, there will be a rejection of the data.  The unsecured ENRP server
should be told what went wrong.

If the PU talks to ENRP without using security then it gets whatever it
gets.  Nothing needs to be done in this case. 

However, if the secure PU talks to the ENRP server and ENRP does not
have security enabled in communication with PEs or other ENRP servers,
then it needs to issue a warning.  I don't think it should reject in
this case, as you might just want to be securing the connection from the
outside.

Thoughts on how to add this?  Does this make sense?  Once we add this, I
think we have a good "chain of trust" argument.

Any other comments on this chain of trust?  I'll send the full writeup
after we debate this issue on the list.  I think everything else is
covered.

-- Maureen
Maureen Stillman
Nokia Enterprise Solutions
Acting Director SMC Systems Architecture

_______________________________________________
rserpool mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rserpool