RT RT/krbdev.mit.edu: Ticket #1445 GSSAPI can fail to generate error in GSS_C_NO_CREDENTIAL case Signed in as guest.
[Logout]

[Home] [Search] [Configuration]

[Display] [History] [Basics] [Dates] [People] [Links] [Jumbo]

 
 

 The Basics  
Id
1445
Status
resolved
Worked
0 min
Priority
0/0
Queue
krb5
 

 Keyword Selections  
Component
  • krb5-libs
Tags
Version_reported
  • 1.3
Version_Fixed
  • 1.12
Target_Version
  • 1.12
 

 Relationships  
Depends on:
Depended on by:
Parents:
Children:

Refers to:
Referred to by:
 
 Dates  
Created: Tue Apr 29 16:23:21 2003
Starts: Not set
Started: Tue Oct 15 00:02:11 2013
Last Contact: Thu Oct 17 18:07:23 2013
Due: Not set
Updated: Wed Dec 16 18:02:39 2015 by tlyu
 

 People  
Owner
 ghudson
Requestors
 hartmans@mit.edu
Cc
 Nicolas.Williams@sun.com
AdminCc
 
 

 More about Sam Hartman  
Comments about this user:
No comment entered about this user
This user's 25 highest priority tickets:
 

History   Display mode: [Brief headers] [Full headers]
      Tue Apr 29 16:23:22 2003  hartmans - Ticket created    
     
To: krb5-bugs@mit.edu
Subject: GSSAPI can fail to generate error in GSS_C_NO_CREDENTIAL case
Date: Tue, 29 Apr 2003 16:23:18 -0400 (EDT)
From: hartmans@MIT.EDU (Sam Hartman)


Nico points out that in accept_sec_context, cred->princ is used as the
server component of the call to krb5_mk_error.


This is problematic because sname and srealm are required fields and
cred->princ can be null in the gss_c_no_credential case.


I believe that if cred->princ is null you can get the principal out of
the decoded ap_req.



Download (untitled) 341b
      Tue Apr 29 16:25:52 2003  hartmans - Cc Nicolas.Williams@sun.com added    
      Tue Apr 29 16:26:46 2003  hartmans - Version_reported 1.3 added    
      Tue Apr 29 16:26:46 2003  hartmans - Component krb5-libs added    
      Tue Apr 29 17:02:27 2003  Nicolas.Williams@sun.com - Comments added    
     
Date: Tue, 29 Apr 2003 13:59:41 -0700
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Sam Hartman via RT <rt-comment@krbdev.mit.edu>
Cc: krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #1445] GSSAPI can fail to generate error in GSS_C_NO_CREDENTIAL case
RT-Send-Cc: 

Which brings us back to a discussion we had at Cthon03: why not always
decode the ap-req and use krb5_rd_req_dec() instead of krb5_rd_req().

IIRC you did not like having the decoding API exposed, so I suggested an
API for querying encoded AP-REQs.  It would also be nice to have an
exposed API to query DER encoded objects for their tag and length.

Cheers,

Nico

On Tue, Apr 29, 2003 at 04:23:24PM -0400, Sam Hartman via RT wrote:
>
>
> Nico points out that in accept_sec_context, cred->princ is used as the
> server component of the call to krb5_mk_error.
>
>
> This is problematic because sname and srealm are required fields and
> cred->princ can be null in the gss_c_no_credential case.
>
>
> I believe that if cred->princ is null you can get the principal out of
> the decoded ap_req.
>
> _______________________________________________
> krb5-bugs mailing list
> krb5-bugs@mit.edu
> http://mailman.mit.edu/mailman/listinfo/krb5-bugs


Download (untitled) 949b
      Thu May  1 19:42:24 2003  hartmans - Correspondence added    
     
To: rt@krbdev.mit.edu
Cc: krb5-prs@mit.edu
Subject: Re: [krbdev.mit.edu #1445] GSSAPI can fail to generate error in GSS_C_NO_CREDENTIAL case
From: Sam Hartman <hartmans@mit.edu>
Date: Thu, 01 May 2003 19:42:19 -0400
RT-Send-Cc: 

>>>>> "Nicolas" == Nicolas Williams via RT <rt-comment@krbdev.mit.edu> writes:

    Nicolas> Which brings us back to a discussion we had at Cthon03:
    Nicolas> why not always decode the ap-req and use
    Nicolas> krb5_rd_req_dec() instead of krb5_rd_req().

Not really.  Or at least I fail to see how your comment is actually
related to the bug or the code.

Note that the code in question already has access to the server
principal from the ap_req because it is in the path that is decoding
it.

Correct solutions include:

* Removivg that code path and not sending back an error token if the ap_req cannot be
read.

* Grabbing the server principal out of the ap-req not out of the credential.


What I'll probably do when I get around to it is grab the the server
princ out of the ap-req if cred->princ is null.



Download (untitled) 818b
      Thu May  1 19:55:59 2003  Nicolas.Williams@sun.com - Correspondence added    
     
Date: Thu, 1 May 2003 16:53:23 -0700
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1445] GSSAPI can fail to generate error in GSS_C_NO_CREDENTIAL case
RT-Send-Cc: 

On Thu, May 01, 2003 at 07:42:26PM -0400, Sam Hartman via RT wrote:
> >>>>> "Nicolas" == Nicolas Williams via RT <rt-comment@krbdev.mit.edu> writes:
>
>     Nicolas> Which brings us back to a discussion we had at Cthon03:
>     Nicolas> why not always decode the ap-req and use
>     Nicolas> krb5_rd_req_dec() instead of krb5_rd_req().
>
> Not really.  Or at least I fail to see how your comment is actually
> related to the bug or the code.
>
> Note that the code in question already has access to the server
> principal from the ap_req because it is in the path that is decoding
> it.
>
> Correct solutions include:
>
> * Removivg that code path and not sending back an error token if the ap_req cannot
be read.

Er, no, please don't do that.  I know that there's no explicit
requirement in RFC2743 that error tokens be sent when there are errors
(heck, rfc2743 does not explicitly mention error tokens, at all) but
it's clear that always sending an error token when there's an error on
the acceptor side while processing a context token is the correct thing
to do.

> * Grabbing the server principal out of the ap-req not out of the credential.

This involves decoding the AP-REQ.

So the code as it stands needs two things, when krb5_rd_req() fails,
from the AP-REQ that krb5_rd_req() does not provide as outputs: the
AP-REQ flags and the target principal name.

So the code decodes the AP-REQ, but does not use krb5_rd_req_dec(),
which means that the decoding happens twice (once inside krb5_rd_req())
for no good reason.

Hence my suggestion that krb5_gss_accept_sec_context() always decode the
AP-REQ and always use krb5_rd_req_dec().

> What I'll probably do when I get around to it is grab the the server
> princ out of the ap-req if cred->princ is null.

This is the correct solution, of course.

Cheers,

Nico
--


Download (untitled) 1.7k
      Tue Oct 15 00:02:11 2013  ghudson - Given to ghudson    
      Tue Oct 15 00:02:11 2013  ghudson - Target_Version 1.12 added    
      Tue Oct 15 00:02:11 2013  ghudson - Status changed from new to review    
      Tue Oct 15 00:02:11 2013  ghudson - Tags pullup added    
      Tue Oct 15 00:02:11 2013  ghudson - Correspondence added    
     
From: ghudson@mit.edu
Subject: git commit


Fix gss_accept_sec_context error tokens

A GSS krb5 error response contains a KRB-ERROR message, which is
required to have a server principal name, although few recipients
actually use it.  Starting in 1.3, accept_sec_context would fail to
encode the error in the GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL case
(introduced by #1370) because cred->princ (which became
cred->name->princ in 1.8) is unset.

This problem got worse in 1.10 because we stopped setting the server
field in all cases due to the changes for #6855.  In 1.11 the problem
got worse again when a misguided change to the mechglue started
discarding output tokens when the mechanism returns an error; the
mechglue should only do so when it itself causes the error.

Fix krb5 gss_accept_sec_context by unconditionally decoding the AP-REQ
and using krb5_rd_req_decoded, and then using the requested ticket
server in the KRB-ERROR message.  Fix the mechglue
gss_accept_sec_context by reverting that part of commit
56feee187579905c9101b0cdbdd8c6a850adcfc9.  Add a test program which
artificially induces a replay cache failure (the easiest failure we
can produce which has an associated RFC 4120 error code) and checks
that this can be communicated back to the initiator via an error
token.

https://github.com/krb5/krb5/commit/c547bc16f2ab6ee66c076ef944c3fbac8a66f5d4
Author: Greg Hudson <ghudson@mit.edu>
Commit: c547bc16f2ab6ee66c076ef944c3fbac8a66f5d4
Branch: master
 src/lib/gssapi/krb5/accept_sec_context.c       |   43 ++++-----
 src/lib/gssapi/mechglue/g_accept_sec_context.c |    6 +-
 src/lib/krb5_32.def                            |    1 +
 src/tests/gssapi/Makefile.in                   |   19 ++--
 src/tests/gssapi/t_err.c                       |  121 ++++++++++++++++++++++++
 src/tests/gssapi/t_gssapi.py                   |    4 +
 6 files changed, 157 insertions(+), 37 deletions(-)


Download (untitled) 1.8k
      Thu Oct 17 18:07:23 2013  tlyu - Status changed from review to resolved    
      Thu Oct 17 18:07:23 2013  tlyu - Version_Fixed 1.12 added    
      Thu Oct 17 18:07:23 2013  tlyu - Correspondence added    
     
From: tlyu@mit.edu
Subject: git commit


Fix gss_accept_sec_context error tokens

A GSS krb5 error response contains a KRB-ERROR message, which is
required to have a server principal name, although few recipients
actually use it.  Starting in 1.3, accept_sec_context would fail to
encode the error in the GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL case
(introduced by #1370) because cred->princ (which became
cred->name->princ in 1.8) is unset.

This problem got worse in 1.10 because we stopped setting the server
field in all cases due to the changes for #6855.  In 1.11 the problem
got worse again when a misguided change to the mechglue started
discarding output tokens when the mechanism returns an error; the
mechglue should only do so when it itself causes the error.

Fix krb5 gss_accept_sec_context by unconditionally decoding the AP-REQ
and using krb5_rd_req_decoded, and then using the requested ticket
server in the KRB-ERROR message.  Fix the mechglue
gss_accept_sec_context by reverting that part of commit
56feee187579905c9101b0cdbdd8c6a850adcfc9.  Add a test program which
artificially induces a replay cache failure (the easiest failure we
can produce which has an associated RFC 4120 error code) and checks
that this can be communicated back to the initiator via an error
token.

(cherry picked from commit c547bc16f2ab6ee66c076ef944c3fbac8a66f5d4)

https://github.com/krb5/krb5/commit/5df4b25fe8e64ca1555662a11a4b8d8b042e048a
Author: Greg Hudson <ghudson@mit.edu>
Committer: Tom Yu <tlyu@mit.edu>
Commit: 5df4b25fe8e64ca1555662a11a4b8d8b042e048a
Branch: krb5-1.12
 src/lib/gssapi/krb5/accept_sec_context.c       |   43 ++++-----
 src/lib/gssapi/mechglue/g_accept_sec_context.c |    6 +-
 src/lib/krb5_32.def                            |    1 +
 src/tests/gssapi/Makefile.in                   |   19 ++--
 src/tests/gssapi/t_err.c                       |  121 ++++++++++++++++++++++++
 src/tests/gssapi/t_gssapi.py                   |    4 +
 6 files changed, 157 insertions(+), 37 deletions(-)


Download (untitled) 1.9k
      Wed Dec 16 18:02:39 2015  tlyu - Keyword pullup deleted