> While you're at it, please note that defining a new scheme "PAM" and > doing the authentication inside the auth loop would be almost > completely effortless because the encapsulation added by the server in > that case could be done with perfect ease inside a generic > conversation function. This ease should be an indication of how much > better that way of doing things would be. It should also serve as an > example that GSSAPI and PAM is really fundamentally the same, because > GSSAPI does it that way. ah! you've just reminded me of the way that CAP_EXTENDED_SECURITY works in SMB [please see draft-leach-cifs-v1-00.txt or imilar, on ftp.icrosoft.com/develpr/drg/cifs NUTS to this damn useless keyboard and ssh/pine with 1000ms round-trip times] ok. SMBnegprot - capabilities bi t CAP_EXT_SEC is set. response: CAP_EXT_SEC bit _also_ set. SMBsesssetupX request: an opaque SPNEGO void*, int len "blob" is sent. SMBsesssetupX response: an opaque SPNEGO "blob" is retuened withan error-status-code STATUS_MORE_PROCESSING-REQUIRED repeat SMBsesssetupXes until security negotiation is completed by the layer *above* the SMB protocol. in this way, the SMB protocool becomes a "trnsport" for authentication, it is totally independent. pam would do well to implement a simplar transport-independendent authentication mechanism.
