Ask HN: Can A give permission to C to access B, without B talking to A?

http://en.wikipedia.org/wiki/File:Kerberos.svg

I generally frown on the "need" for higher education as a requirement for work, but this is pretty basic stuff?

On the off chance that it wasn't, perhaps you want to look into ssh certificates (as an alternative to kerberos), or CAS for a way to deploy something kerberos-like for web:

http://jasig.github.io/cas/4.0.x/protocol/CAS-Protocol.html

For web, one of the big issues with login is managing both Single-Sign On (eg: you can be logged into an authentication provider like gmail or facebook, and then not have to authenticate again (with eg. login/pw) to use a different service (like... um... blogger or flickr or something that delegates authentication (who you are), and does authoriation based on that (now that I know who you are, what are you allowed to do).

And managing Single-Sign Out: when you log out from one service, all tokens/sessions etc are logged out. So if you click logout in flickr, you're also logged out from facebook.

As for ssh certificates, they (can) AFAIK embed information on who you are (uid) and where you can log in from (source-ip), and where you can log in to (uid@host), along with an expiry date. The client gets a cert from the CA, the ssh server gets a cert from the CA, and the ssh server can look at the cert and see a) it's valid, b) it's valid for user X, c) it's valid for user X from ip n.n.n.n and d) it's valid for user X@server.

It does not allow for too fine grained delegation of authorization without some other method (eg: communication between the ssh server and a trusted authority, like radius, ldap etc).

[ed: as others noted, see also x509, of which ssh certs is a simplification, intended for use with ssh]

Does anyone have any insight to what the state of the art is marrying kerberos ideas and nacl? I found this:

http://www.slideshare.net/pieterh/zeromq-security

But it is obviously somewhat dated now -- did zeromq+sasl+nacl go anywhere? In what form? I'd hoped that this would "get sorted" and allow saltstack to leverage something a little more standard (which would alleviate my last doubts about salt -- but my fears might be unfounded -- I've just not seen anything that really addresses the early issues they had with security/transport/encryption).

Anyone using: https://github.com/zeromq/libcurve in anger?

Finally, I can't resist posting this soundtrack that I had serendipitously playing in the background as I read the above slidedeck: "Nothin' - Townes Van Zandt". Seemed oddly appropriate to go along with forward secrecy:

https://www.youtube.com/watch?v=zZcH2OOMV4A

Also note, I answered my own question with HMAC being the probable solution (before anyone else mentioned HMAC), and others seemed to verify that this might be the best fit by answering with the same thing shortly thereafter. If I can give permission and I only need to provide permission, the only thing I only need is a way to transmit a message and prove that it wasn't modified while in-transit.

This is especially true in authentication and access control, sometimes call IDAM (look that up, read, learn).

You may do so well as to cover the vast majority of cases. Yet I guarantee you will leave an exploitable edge case that will leave your systems vulnerable. If they are Internet-facing, these vulnerabilities will be exploited, probably without you knowing it.

I encourage to read about prevent, detect, respond, and recover, about defence in depth, about Kerberos, about PKI in general, about SSL and TLS and SSH specifically, and about IDAM.

Do NOT attempt this on a production server until you know in your heart and gut and mind what was wrong with SSL v1 and v2, what is wrong with v3, and why we are now at TLS 1.2.

Do not attempt this until you understand why having keepalives outside the security envelope is a flaw in any security protocol - or until you can argue clearly and cleanly why it may not be important in your case.

Once you understand those things, you may start to understand how much you are missing. Learn about SPEKE, e.g., that will help too.

I've been a security consultant for a long time, was a development manager and developer before that. Everybody gets their first implementation wrong. Everyone.