[18924] in Kerberos_V5_Development
Re: [PATCH] Fix SPNEGO interoperability with servers implementing
daemon@ATHENA.MIT.EDU (David Woodhouse)
Mon Aug 4 10:10:36 2014
Message-ID: <1407161416.28796.1.camel@infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
To: Greg Hudson <ghudson@mit.edu>
Date: Mon, 04 Aug 2014 15:10:16 +0100
In-Reply-To: <53D2E0C1.8000604@mit.edu>
Mime-Version: 1.0
Cc: krbdev@mit.edu
Content-Type: multipart/mixed; boundary="===============0229807694=="
Errors-To: krbdev-bounces@mit.edu
--===============0229807694==
Content-Type: multipart/signed; micalg="sha-1";
protocol="application/x-pkcs7-signature";
boundary="=-uFABULvk/Tuui7d+nmqi"
--=-uFABULvk/Tuui7d+nmqi
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, 2014-07-25 at 18:57 -0400, Greg Hudson wrote:
> On 07/25/2014 03:45 PM, David Woodhouse wrote:
> > If that isn't the intention, the I wonder why the request-mic state was
> > added at all.
>=20
> I'm not sure. It wouldn't be the first time that a protocol used
> explicit state where implicit state would serve.
No, it's much more than that.
You are quite right that it's not unheard-of for protocols to use
explicit state where implicit state would serve. (And sometimes that
makes sense, for forward compatibility. You might explicitly know the
state *today* but in future new possibilities might be added.)
But this additional state was *added* to an existing protocol.
If the intention was that new servers and clients must *always* require
MIC processing without regard to backward compatibility, there was
absolutely no need for that change. Just send and check/require the MIC
unconditionally (when the underlying mechanism supports it), and that's
all there is to it.
The only way that the addition of the REQUEST-MIC state makes sense, is
for clients to be able to tell the difference between RFC4178-compliant
and older servers.
Furthermore, in your interpretation it's not just redundant state on the
wire. There's also verbiage in the RFC which would be entirely
redundant, where it *explicitly* sets out how a client should behave
when a server doesn't send the REQUEST-MIC state in its reply.
Seriously, the *only* logic that makes sense for the change is that it
allows clients to interoperate with older servers.
FWIW I tested on Windows 7, with a fake server. My client (using SSPI)
sends a Kerberos token, and the server sends back:
Proxy-Authenticate: Negotiate oRUwE6ADCgEBoQwGCisGAQQBgjcCAgo=3D
That is, a SPNEGO "no, try GSS-NTLMSSP" with ACCEPT-INCOMPLETE. At which
point Windows happily falls back to GSS-NTLMSSP as requested.
This behaviour matches my reading of the specification, and I'm fairly
certain that it *is* what they intended.
Now, that doesn't mean we *have* to do what they intended, of course.
But it's a fairly strong hint in that direction.
> > A server compliant with RFC4178 will not only send request-mic, but it
> > will also expect us to actually *send* a MIC. If a hypothetical attacke=
r
> > downgrades 'request-mic' in the reply to 'accept-incomplete', the serve=
r
> > isn't actually going to accept our authentication, surely?
>=20
> I think the server will wind up returning accept-incomplete because it
> hasn't yet received a mic from the client. But the client won't
> necessarily see that; the attacker could alter the final message from
> the server to have accept-complete state.
If it's the client that sends the last token, as is the case in NTLMSSP,
there's no downgrade attack here. Either we send our final packet
without a MIC, or perhaps we'd send it with an unsolicited MIC of the
tampered packets, and either way the server is doing to reject that.=20
If it's the server that sends the last token, then still we're never
going to be able to authenticate to that server because it'll be waiting
for a MIC. But you are correct that the attacker could alter the final
message to have ACCEPT-COMPLETE state, and fool us into thinking that we
succeeded. Although we'd be left with a GSSAPI context which isn't
actually *useful* for anything, because the server will hate us.
Maybe I'm missing a reason why we'd really care about that, given that
an attacker could have bypassed the whole exchange and just made it look
like the server didn't require authentication in the first place.
But I'm not going to lose sleep over that. Given the limited
circumstances in which the fallback is necessary, it would be perfectly
acceptable to accept fallback without REQUEST-MIC *only* if the
mechanism being requested is one where the client sends the final token.
Or indeed, *only* if the mechanism is NTLMSSP.
Like this, for example...
=46rom ec9988362314819963e025aee5b0deca28a98eb6 Mon Sep 17 00:00:00 2001
From: David Woodhouse <David.Woodhouse@intel.com>
Date: Fri, 25 Jul 2014 11:10:01 +0100
Subject: [PATCH] Fix SPNEGO interoperability with servers implementing RFC2=
478
MIME-Version: 1.0
Content-Type: text/plain; charset=3DUTF-8
Content-Transfer-Encoding: 8bit
Servers running Windows 2003 and earlier do not send a negState of
request-mic in their initial reply when the first mechanism is
declined. That's because they implement (roughly) RFC2478, which
predates the addition of the request-mic state.
A server conforming to RFC4178 MUST send request-mic there, but it
is equally clear that on the client side, we should deal with its
absence. For example, the language in =C2=A75 (c) is as follows:
"if the negState was request-mic in the first reply from the
target, a mechlistMIC token MUST be included; otherwise..."
In the MIT implementation as it stands, there is no "otherwise".
Because we already overzealously aborted the negotiation.
Other language in RFC4178 which supports this interpretation includes
the whole of Appendix C, which explains the changes since RFC2478.
Looking at that, in fact it seems that the addition of request-mic on
the wire was done specifically to allow interoperability with older
implementations which don't set it. If not for that consideration,
and if we were only ever communicating between RFC4178-compliant
implementations, we could always have just behaved as if request-mic
were set =E2=80=94 and there would be no need to *say* so on the wire.
Testing on Windows 7 shows that the Windows client *will* continue in
this situation without using a MIC, as requested by the server.
This change does NOT make us vulnerable to a downgrade attack where an
attacker changes request-mic in a server's response to accept-incomplete.
The server in any such situation is still going to be looking for the
MIC that it asked for. And when we fail to send one (or if we send one
but we've hashed the tampered packets), the server is going to reject
our authentication.
In the case where the final mechanism token is sent from client to
server, the server will reject our authentication attempt outright.
This is, in fact, the case we see in practice because it is NTLMSSP
that the affected servers will be asking us to fall back to.
In the case where the final mechanism token is sent from server to
client, the server will send its final token with accept-incomplete
state indicating that it is waiting for the MIC. A hypothetical
attacker could change that to accept-complete, thus tricking us into
thinking that the authentication succeeded. It's not entirely clear
what practical purpose this could serve in any situation, since
the context *isn't* established and the server *hasn't* authenticated
us. But we don't need to lose sleep over that. We *only* need to allow
NTLMSSP for this fallback anyway, so just disallow it for any other
mechanisms.
---
src/lib/gssapi/spnego/spnego_mech.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/src/lib/gssapi/spnego/spnego_mech.c b/src/lib/gssapi/spnego/sp=
nego_mech.c
index 2aa6810..0abe175 100644
--- a/src/lib/gssapi/spnego/spnego_mech.c
+++ b/src/lib/gssapi/spnego/spnego_mech.c
@@ -806,6 +806,9 @@ init_ctx_nego(OM_uint32 *minor_status, spnego_gss_ctx_i=
d_t sc,
return ret;
}
=20
+static const gss_OID_desc gss_mech_ntlmssp_oid =3D
+ { 10, "\x2b\x06\x01\x04\x01\x82\x37\x02\x02\x0a" };
+
/*
* Handle acceptor's counter-proposal of an alternative mechanism.
*/
@@ -831,17 +834,20 @@ init_ctx_reselect(OM_uint32 *minor_status, spnego_gss=
_ctx_id_t sc,
sc->internal_mech =3D &sc->mech_set->elements[i];
=20
/*
- * Windows 2003 and earlier don't correctly send a
- * negState of request-mic when counter-proposing a
- * mechanism. They probably don't handle mechListMICs
- * properly either.
+ * A server conforming to RFC4178 MUST set REQUEST_MIC here
+ * but Windows 2003 and earlier implement (roughly) RFC2478
+ * instead, and send ACCEPT_INCOMPLETE. Tolerate that *only*
+ * if they are asking us to fall back to NTLMSSP.
*/
- if (acc_negState !=3D REQUEST_MIC)
+ if (acc_negState =3D=3D ACCEPT_INCOMPLETE) {
+ if (!g_OID_equal(supportedMech, &gss_mech_ntlmssp_oid))
+ return GSS_S_DEFECTIVE_TOKEN;
+ } else if (acc_negState !=3D REQUEST_MIC)
return GSS_S_DEFECTIVE_TOKEN;
=20
sc->mech_complete =3D 0;
- sc->mic_reqd =3D 1;
- *negState =3D REQUEST_MIC;
+ sc->mic_reqd =3D (acc_negState =3D=3D REQUEST_MIC);
+ *negState =3D acc_negState;
*tokflag =3D CONT_TOKEN_SEND;
return GSS_S_CONTINUE_NEEDED;
}
--=20
1.9.3
--=20
dwmw2
--=-uFABULvk/Tuui7d+nmqi
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISxDCCBjQw
ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX
DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK
75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC
+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD
z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr
/+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc
fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG
XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt
UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R
HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv
sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s
sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq
+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT
zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq
Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1
9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGQjCCBSqg
AwIBAgIDCdkyMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN
MTQwNTA0MTczMDIyWhcNMTUwNTA0MjM0MTAxWjBdMRkwFwYDVQQNExAzODNCMTVkSHFQSUR0cDZO
MRwwGgYDVQQDDBNkd213MkBpbmZyYWRlYWQub3JnMSIwIAYJKoZIhvcNAQkBFhNkd213MkBpbmZy
YWRlYWQub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy7K+t+REIdZGFUfgR8Io
QrJ/VLZil9I00JcwqTo8BiGy1dqSIB2y923siya5SDKMh1YurtCPsX96cNzwPmmN2cs0MKeVPQWz
iQhHk3uKcB6LvvS7pzTahRWMRmTyW3CH+RphRM9plvyClY23GEeEnpBnGz4GaJJiPcJjGgzyZ/tI
q473pOlSrDPZnZk43vt/5CJN46nIZOZ2I+PzlgINI+EbiwsXVn3VohHB7nVTwGaRLk5oywGt8ZT7
tDdxn3BQ3inO1sr5MtkV1o2cHlenIC8mlU8nL/mrqqVve7Vib1YQUycW+Pj4CBYm4FTeuctAvNzK
U/daeBclOZ8ofgQe2wIDAQABo4IC2TCCAtUwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRAjCSCV70BpLBeXge5DXi+mPhHTTAf
BgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAeBgNVHREEFzAVgRNkd213MkBpbmZyYWRl
YWQub3JnMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEW
Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0
YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdh
cyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRz
IG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRl
ZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMu
MDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmww
gY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9z
dWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20v
Y2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh
cnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAWS2KNN7O3vZVtNHXVqgbmijeptKwt+8b6yiF
wT3kJoywInPl5U+OeKRZfQKTHghM4Ohof6lF244ZMxhir/xp7l/zkZ/BUbxLwp6kIL27Gi5pgP4D
KLnTZheQL9N5Yi/vMONxMWcpcW+ZNv5hnDCfEsfVcLXC8sNLPjx2ezfMIhSSPwBuJpmOun70te4E
P0YBqjSalPfvc5fC5KgaYtqTDFwo9Mw25X5HHDC0r6BK5aNrF1nD/xYTX7cdvZZWl7cUApr4PCrn
uI2DEn7OWQ/rY407ytV1c5pjvmuv/IT/ZUb/kXV6Q47UvrJp2Ifi2VhsBcnHHasKavjtRCmpDsGM
rTCCBkIwggUqoAMCAQICAwnZMjANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBMB4XDTE0MDUwNDE3MzAyMloXDTE1MDUwNDIzNDEwMVowXTEZMBcGA1UEDRMQMzgzQjE1
ZEhxUElEdHA2TjEcMBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYT
ZHdtdzJAaW5mcmFkZWFkLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMuyvrfk
RCHWRhVH4EfCKEKyf1S2YpfSNNCXMKk6PAYhstXakiAdsvdt7IsmuUgyjIdWLq7Qj7F/enDc8D5p
jdnLNDCnlT0Fs4kIR5N7inAei770u6c02oUVjEZk8ltwh/kaYUTPaZb8gpWNtxhHhJ6QZxs+BmiS
Yj3CYxoM8mf7SKuO96TpUqwz2Z2ZON77f+QiTeOpyGTmdiPj85YCDSPhG4sLF1Z91aIRwe51U8Bm
kS5OaMsBrfGU+7Q3cZ9wUN4pztbK+TLZFdaNnB5XpyAvJpVPJy/5q6qlb3u1Ym9WEFMnFvj4+AgW
JuBU3rnLQLzcylP3WngXJTmfKH4EHtsCAwEAAaOCAtkwggLVMAkGA1UdEwQCMAAwCwYDVR0PBAQD
AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUQIwkgle9AaSwXl4H
uQ14vpj4R00wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHgYDVR0RBBcwFYETZHdt
dzJAaW5mcmFkZWFkLm9yZzCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4G
CCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcC
AjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0
aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJl
cXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0
aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9i
bGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFy
dHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3Rh
cnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAFktijTezt72VbTR11aoG5oo
3qbSsLfvG+sohcE95CaMsCJz5eVPjnikWX0Ckx4ITODoaH+pRduOGTMYYq/8ae5f85GfwVG8S8Ke
pCC9uxouaYD+Ayi502YXkC/TeWIv7zDjcTFnKXFvmTb+YZwwnxLH1XC1wvLDSz48dns3zCIUkj8A
biaZjrp+9LXuBD9GAao0mpT373OXwuSoGmLakwxcKPTMNuV+RxwwtK+gSuWjaxdZw/8WE1+3Hb2W
Vpe3FAKa+Dwq57iNgxJ+zlkP62ONO8rVdXOaY75rr/yE/2VG/5F1ekOO1L6yadiH4tlYbAXJxx2r
Cmr47UQpqQ7BjK0xggNvMIIDawIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2
BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMJ
2TIwCQYFKw4DAhoFAKCCAa8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx
DxcNMTQwODA0MTQxMDE2WjAjBgkqhkiG9w0BCQQxFgQUNoKTHRxv2FEbOuoseF2uyK4LNLkwgaUG
CSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0
YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMJ2TIwgacGCyqG
SIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr
MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh
cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwnZMjANBgkqhkiG
9w0BAQEFAASCAQBkUpewuYsxpjehg7mM65M4ajIBHgCCTexvC0HSpmKLmNYAsZpK+h1mBaC2roVt
914zv2s/sLDaUSpam8airv2iDpnb5y3AEsgCFYg+WmApARFQa25mUGu/bsiBTn4msW2QpzXp5A/O
ipgp2g4jtoWW9GlyEd66K21u0tsj5G+1bv6+Fqxq7cUIgufF1xTOHi6fTw1yOF5jDVd7ZNJJtn3K
FsW51z8Sw19ewy2l08uZ4qEV2NW7Gbx18iA4n4Q42PXA8ItCk25a6kmKRktVZLM6MIgJDnGQKzuV
NuxQFrcXFLyzFi/HlXRGrDRXG8mZ4+vKhtLQh0SKIne2bSun3rJBAAAAAAAA
--=-uFABULvk/Tuui7d+nmqi--
--===============0229807694==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
--===============0229807694==--
