From 19719df3b5e421192de3ba1577bddca3cc396453 Mon Sep 17 00:00:00 2001 From: Ken Raeburn Date: Sat, 25 May 2002 02:33:52 +0000 Subject: [PATCH] reformat comment git-svn-id: svn://anonsvn.mit.edu/krb5/trunk@14452 dc483132-0cff-0310-8789-dd5450dbe970 --- src/lib/gssapi/krb5/accept_sec_context.c | 40 +++++++++++++----------- 1 file changed, 21 insertions(+), 19 deletions(-) diff --git a/src/lib/gssapi/krb5/accept_sec_context.c b/src/lib/gssapi/krb5/accept_sec_context.c index f4d539122..08f90e8e1 100644 --- a/src/lib/gssapi/krb5/accept_sec_context.c +++ b/src/lib/gssapi/krb5/accept_sec_context.c @@ -98,25 +98,27 @@ rd_and_store_for_creds(context, auth_context, inbuf, out_cred) krb5_auth_con_setflags(context, auth_context, KRB5_AUTH_CONTEXT_DO_SEQUENCE); - /* By the time krb5_rd_cred is called here (after krb5_rd_req has been */ - /* called in krb5_gss_accept_sec_context), the "keyblock" field of */ - /* auth_context contains a pointer to the session key, and the */ - /* "remote_subkey" field might contain a session subkey. Either of */ - /* these (the "remote_subkey" if it isn't NULL, otherwise the */ - /* "keyblock") might have been used to encrypt the encrypted part of */ - /* the KRB_CRED message that contains the forwarded credentials. (The */ - /* Java Crypto and Security Implementation from the DSTC in Australia */ - /* always uses the session key. But apparently it never negotiates a */ - /* subkey, so this code works fine against a JCSI client.) Up to the */ - /* present, though, GSSAPI clients linked against the MIT code (which */ - /* is almost all GSSAPI clients) don't encrypt the KRB_CRED message at */ - /* all -- at this level. So if the first call to krb5_rd_cred fails, */ - /* we should call it a second time with another auth context freshly */ - /* created by krb5_auth_con_init. All of its keyblock fields will be */ - /* NULL, so krb5_rd_cred will assume that the KRB_CRED message is */ - /* unencrypted. (The MIT code doesn't actually send the KRB_CRED */ - /* message in the clear -- the "authenticator" whose "checksum" ends up */ - /* containing the KRB_CRED message does get encrypted.) */ + /* + * By the time krb5_rd_cred is called here (after krb5_rd_req has been + * called in krb5_gss_accept_sec_context), the "keyblock" field of + * auth_context contains a pointer to the session key, and the + * "remote_subkey" field might contain a session subkey. Either of + * these (the "remote_subkey" if it isn't NULL, otherwise the + * "keyblock") might have been used to encrypt the encrypted part of + * the KRB_CRED message that contains the forwarded credentials. (The + * Java Crypto and Security Implementation from the DSTC in Australia + * always uses the session key. But apparently it never negotiates a + * subkey, so this code works fine against a JCSI client.) Up to the + * present, though, GSSAPI clients linked against the MIT code (which + * is almost all GSSAPI clients) don't encrypt the KRB_CRED message at + * all -- at this level. So if the first call to krb5_rd_cred fails, + * we should call it a second time with another auth context freshly + * created by krb5_auth_con_init. All of its keyblock fields will be + * NULL, so krb5_rd_cred will assume that the KRB_CRED message is + * unencrypted. (The MIT code doesn't actually send the KRB_CRED + * message in the clear -- the "authenticator" whose "checksum" ends up + * containing the KRB_CRED message does get encrypted.) + */ if (krb5_rd_cred(context, auth_context, inbuf, &creds, NULL)) { if (retval = krb5_auth_con_init(context, &new_auth_ctx)) goto cleanup; -- 2.26.2