Skip to content

Commit 8bac494

Browse files
Add security consideration section (#221)
* WIP: Add security conscideration section This is required in an IETF standard, we should do a lot more work on it though. * Update IETF-RFC.md Co-authored-by: Giuseppe Lo Presti <giuseppe.lopresti@cern.ch> * Update IETF-RFC.md Co-authored-by: Giuseppe Lo Presti <giuseppe.lopresti@cern.ch> * Update IETF-RFC.md Co-authored-by: Giuseppe Lo Presti <giuseppe.lopresti@cern.ch> * Update IETF-RFC.md Co-authored-by: Giuseppe Lo Presti <giuseppe.lopresti@cern.ch> --------- Co-authored-by: Giuseppe Lo Presti <giuseppe.lopresti@cern.ch>
1 parent 9675672 commit 8bac494

1 file changed

Lines changed: 28 additions & 0 deletions

File tree

IETF-RFC.md

Lines changed: 28 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -897,6 +897,34 @@ request or not.
897897
# IANA Considerations
898898
This document has no IANA actions.
899899

900+
# Security Considerations
901+
## Trust
902+
There are several areas that are not covered by this specification. Most
903+
importantly we do not provide a way of establishing trust between
904+
servers, even though some features of the protocol rely on trust, such
905+
as the `mfa-enforced` requirement.
906+
907+
Trust needs to be established out of band, but there are some features
908+
of the protocol that _can_ be used to assist operators in establishing
909+
trust. For instance, invite flow can be used to establish that users
910+
know and have out of band connections with other users on an OCM server.
911+
912+
Further more the Directory Service feature can be used to establish a
913+
trusted federation, where a central authority can be trusted to
914+
implement measures for auditing and adding only trusted servers into the
915+
discovery service.
916+
917+
### httpsig
918+
It is recommended to use signed messages to verify that an OCM server
919+
is the server you expect it to be, and should be done unless you have
920+
a niche use case.
921+
922+
## Legacy shared secrets
923+
The legacy format of an OCM Share Notification with shared secrets is
924+
only provided for backwards compatibility with existing implementations.
925+
Implementers SHOULD NOT use it and prefer short-lived tokens instead.
926+
927+
900928
# Appendix A: Multi Factor Authentication
901929
If a Receiving Server exposes the capability `enforce-mfa`, it
902930
indicates that it will try and comply with a MFA requirement set on a

0 commit comments

Comments
 (0)