[OpenAFS-devel] Anyone supporting multiple realms in a "all realms are equal" type of setup?

[Jeffrey Altman]

This is a cryptographically signed message in MIME format.

--------------ms070701030804060904090506
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Douglas E. Engert wrote:


> But the need for gssklog came from AFS cells that had kaserver but
> not krb5 and wanted to use the Globus GSI, and where not willing to setup
> a krb5 cell.  So I don't think you as the developer can force AFS
> to only work with one. You can internally with the token, but
> AFS may want to keep its options open to support multiple methods
> of obtaining a token.

I as a developer certainly can determine what mechanisms I support
in the tools that I develop.  Currently, the OpenAFS for Windows
client only supports Kerberos 5 OR Kerberos 4.  One of the primary
reasons is due to the lack of resources to build a user interface
capable of managing in a reasonable way all of the choices the
user would have to make for each and every cell.

If organizations want this to change, I strongly urge them to make
donations.  I estimate the work on the new UI to take about four
months.

> AFS needs to work with what ever authentication method is available.
> It might be the default is no mapping service i.e. use k5 tickets
> directly with a single or multiple realms, or one that supports only
> K5 via gssapi, or other gssapi mechenisums.

I completely agree with the statement "AFS needs to work with whatever
authentication method is available".  However, our interpretation of
this statement is very different.  For me, this statement means that
the AFS servers need to be aware of all the authentication IDs which
might be presented by clients using available authentication methods.

There is a distinction between the justification you provided above
for the creation of gssklogd and the mapping service you implemented
within it for Kerberos 5 principals.  I believe that gssklogd is a
perfectly fine service for organizations that do not want to use
Kerberos 5.  However, once they are committed to deploying Kerberos 5
the gssklogd cannot be used to perform arbitrary principal mappings.
Doing so results in the situation that many organizations who performed
similar mappings in krb524d are facing.

You make it impossible for a Kerberos 5 ticket to be used directly
as a token even though the KDC is more then willing to issue it.
In my view, if the KDC is going to issue an "afs" or "afs/cell"
service ticket, then that ticket must be usable as a token without
modification by some arbitrary service.

I am not saying that you cannot use gssklogd.  But if you do it should
not work by requesting "afs" or "afs/cell" service tickets.  Come up
with some other service name and use that.  By doing so you make it
clear that those service tickets are not useful without the intermediate
service.

If you want to push the mapping into gssklogd in which authentication
is performed using GSS-Kerberos 5, then the KDC had better not issue
"afs" or "afs/cell" tickets directly to clients.

> Even if AFS does not provide a maping service, it can still be done
> as this is what the gssklog did.

In order to support all of the different authentcation mechanisms
in a general way, the ptserver is going to have to provide extensions
allowing a mapping of names to IDs.  This does not prevent you from
doing the mapping somewhere else provided that you appropriately
differentiate it from the Kerberos 5 "afs" service name.

> Also note the multiple akog, afslogin, PAM routines and code built
> into daemons today to get tokens. How would you simplify
> this?

This code is absolutely gross.  The only way to simplify it is to
develop a new standard for authenticating to cells and eventually
abandoning the old code.

MIT Kerberos is going to abandon Kerberos 4.  OpenAFS will have to do
so as well.  At some point we simply have to say that we only support
Kerberos 5 or XXX and that all of the old hacks will no longer work.
This is not going to happen in the next year, but it should happen
within five years.

Unfortunately, which PAM you use or which mods you make to OpenSSH
are highly dependent on the infrastructure of the cell you are
attempting to authenticate to.  Hence, end users or system 
administrators must have access to knowledge and expertise they
should not be required to know.

>> End users should not be aware of such issues. 
> 
> I agree with that.

At least that is something.

Jeffrey Altman


--------------ms070701030804060904090506
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJPzCC
AvowggJjoAMCAQICAwxk8TANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNTI3MTc1ODU4WhcNMDUwNTI3MTc1ODU4
WjBrMQ8wDQYDVQQEEwZBbHRtYW4xFTATBgNVBCoTDEplZmZyZXkgRXJpYzEcMBoGA1UEAxMT
SmVmZnJleSBFcmljIEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5l
ZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc3JqO5AsZrozd+mJ2mPuCTYo2
+nJ9Qq6jtUYtp7YTMW4d2Q6GLhNaHb1l9m74SxuY4f5vP6JtZjr6p9+LCCxD0w0NVLKRgUDp
z+tKFitbkJe9BSCxCURRvY3vdWA71gSCUvZAN3346hHb4oGVqgdpmfFJXYAHWpC46wiL72N9
WxySzY17/0eU0c8+r9dNoLpPQeL43O66O80jCl1qnXMaXaakZPsfm+5W90MYXhpQ1WIQpv02
lBn3BH5YE8xwbsNrw5AF4v7pjMuW85GI6FrDmfbpJX473Rpl5rmv3TpXkJ+7UsIIO1puyS8r
1o7kjDZ5EUYJxxglTGR6XL/RNzqHAgMBAAGjMTAvMB8GA1UdEQQYMBaBFGphbHRtYW5AY29s
dW1iaWEuZWR1MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEEBQADgYEAZYeVFCMP0iV+UVa0
eFoXkzMVl61CNAVY2YQ9/QQazO3G4qNiif35ArrnjPRDRj5M7WTeOCFqPVuvCttyJRiDKsEe
L4Yah22mRA3mR7x52j2FquPYZ9qCr1IhrNGzsMk+gopX5G0fTHZb6+uDu5SeMPNNcIznGA7M
CMpXAJ2PcKgwggL6MIICY6ADAgECAgMMZPEwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro
YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA0MDUyNzE3NTg1OFoXDTA1
MDUyNzE3NTg1OFowazEPMA0GA1UEBBMGQWx0bWFuMRUwEwYDVQQqEwxKZWZmcmV5IEVyaWMx
HDAaBgNVBAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5A
Y29sdW1iaWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3NyajuQLGa6M
3fpidpj7gk2KNvpyfUKuo7VGLae2EzFuHdkOhi4TWh29ZfZu+EsbmOH+bz+ibWY6+qffiwgs
Q9MNDVSykYFA6c/rShYrW5CXvQUgsQlEUb2N73VgO9YEglL2QDd9+OoR2+KBlaoHaZnxSV2A
B1qQuOsIi+9jfVscks2Ne/9HlNHPPq/XTaC6T0Hi+NzuujvNIwpdap1zGl2mpGT7H5vuVvdD
GF4aUNViEKb9NpQZ9wR+WBPMcG7Da8OQBeL+6YzLlvORiOhaw5n26SV+O90aZea5r906V5Cf
u1LCCDtabskvK9aO5Iw2eRFGCccYJUxkely/0Tc6hwIDAQABozEwLzAfBgNVHREEGDAWgRRq
YWx0bWFuQGNvbHVtYmlhLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAGWH
lRQjD9IlflFWtHhaF5MzFZetQjQFWNmEPf0EGsztxuKjYon9+QK654z0Q0Y+TO1k3jghaj1b
rwrbciUYgyrBHi+GGodtpkQN5ke8edo9harj2Gfagq9SIazRs7DJPoKKV+RtH0x2W+vrg7uU
njDzTXCM5xgOzAjKVwCdj3CoMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBT
ZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENB
MSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcx
NzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0
ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnK
mVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/
cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8
YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4
oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5j
cmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwy
LTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4
Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowg
T2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAzswggM3AgEB
MGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0
ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMZPEw
CQYFKw4DAhoFAKCCAacwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx
DxcNMDQwOTIyMTcwNjQ1WjAjBgkqhkiG9w0BCQQxFgQUlkGAEYWbJO+GxIkQ1tO0SS9Ewfgw
UgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcN
AwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYD
VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE
AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwxk8TB6BgsqhkiG9w0B
CRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB
AgMMZPEwDQYJKoZIhvcNAQEBBQAEggEAc/B4xAGELhzzMr0h70lM1A2npQmnzFOCLoAAueWP
WdvaixPDcyt5qGMAbeK3bvG0QCgD+cb8i8j2EaEFIFNVO2KIr3FkkxZ2hvlIld/IWTXdbxZS
tN/qLdWM+92Zy5SpCAZYvr6ZKktkqKFaq8jWIIWKFkwomkZAfqfVdm19OGtsrFc50YaAyzO/
7zf6IgfdAv5CP16CetyL+R2iLGpVcfD9yUa8Pb8lruKTevl1vfkIKf6sRmX9nFP4zA3wGWaZ
9UNolxX8evJfWelyKENG9pdfbfSwHzQ7RcU1shg8RGybq9nVxxyjwQZf6GLTVwu7fDwWuiaK
JQxnyjCRWHPF0wAAAAAAAA==
--------------ms070701030804060904090506--