GSS-API and libkrb5 behavior for Anonymous tickets

[Sam Hartman]

I'm starting the writeup for http://k5wiki.kerberos.org/wiki/Projects/Anonymous_pkinit .

I have a couple of questions about API behavior.

Note that as I'm proposing to implement this project, getting
anonymous tickets will not always work. There are two main causes of
failure.  First, your client may not be configured to verify the
certificate that the KDC presents.  Secondly, the KDC may not have
anonymous tickets enabled.

I have two questions about API behavior.

The first is what should the GSS-API behavior of the anonymous context
establishment option be.  

* If I set the anonymous option and pass in the default credential handle, what happens?  Options include:

1) If I have anonymous credentials in my default cache, I use them and
get the anonymous bit set in the established context.  Otherwise, I
don't get anonymous set in my context and I use the existing
credentials.  We call this the pathetic option.
[I recommend against this option.]

2) If my default credentials are anonymous they are used and the
anonymous bit is set in the context.  Otherwise, if I'm able to obtain
anonymous credentials, I do so into a memory ccache.  If I fail to
obtain anonymous credentials, then I use my existing default
credentials and don't set the anonymous bit in the context.  This
option is probably maximally conforming to the intent of the GSS-API
spec.

3) Option 2 as above, except that if I fail to obtain anonymous
credentials, I return an error.  This allows us to debug being unable
to obtain anonymous credentials, but probably breaks the strict
interpretation of how GSS-API should work.

* If I pass the anonymous name into gss_acquire_credentials, what
  happens?

1) If my default credentials are anonymous, then it works.  Otherwise, if I'm using KIM I may try to obtain anonymous credentials, but on Unix I fail.

2) If my default credentials are anonymous I use them.  Otherwise, I set up a new memory ccache and try to obtain anonymous credentials.  If I fail, I return an error.

3) Option 2 as above, except that if I fail to obtain anonymous
credentials, then  I use my default credentials.

Then I have some questions about libkrb5.

Several things need to happen to request anonymous credentials from an AS:

* You need the anonymous principal name as the client
* You need the anonymous KDC option set
* You must use pkinit with DH

First krb5 question: How much work should krb5_get_init_creds do to
make things consistent.  For example, should setting the client
principal name to anonymous set the anonymous option?  Should setting
the anonymous option set the client principal name?  Should either of
the above force pkinit?

Second question: I want to introduce an API that takes a realm and a
ccache and tries to obtain anonymous credentials for that realm.  Does
this sound good?
_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Nicolas Williams]

If you use the anonymous req_flag and a non-default credential handle,
and the credential handle is for anonymous desired_name, then there's no
"pathetic" fallback on non-anonymous authentication.

But if you use the anonymous req_flag and the default credential handle,
then technically the mechanism is free to not give you anonymity.

Given that there's a way to get anonymity-or-failure, I don't mind what
you call the "pathetic option".

> * If I pass the anonymous name into gss_acquire_credentials, what
>   happens?

You should get credentials.

> 1) If my default credentials are anonymous, then it works.  Otherwise,
> if I'm using KIM I may try to obtain anonymous credentials, but on
> Unix I fail.

Why do you fail?

> 2) If my default credentials are anonymous I use them.  Otherwise, I
> set up a new memory ccache and try to obtain anonymous credentials.
> If I fail, I return an error.

Yes.

> 3) Option 2 as above, except that if I fail to obtain anonymous
> credentials, then  I use my default credentials.

No!

> Then I have some questions about libkrb5.
>
> Several things need to happen to request anonymous credentials from an AS:
>
> * You need the anonymous principal name as the client
> * You need the anonymous KDC option set
> * You must use pkinit with DH
>
> First krb5 question: How much work should krb5_get_init_creds do to
> make things consistent.  For example, should setting the client
> principal name to anonymous set the anonymous option?  Should setting
> the anonymous option set the client principal name?  Should either of
> the above force pkinit?

Yes, yes, and yes only if a pre-auth method wasn't requested by the app.

> Second question: I want to introduce an API that takes a realm and a
> ccache and tries to obtain anonymous credentials for that realm.  Does
> this sound good?

Yes.

Nico
--
_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[ghudson-2]

Does Heimdal have anonymous pkinit support yet?  We should try to be
consistent with its behavior if so.

My preference for gss_init_sec_context behavior is option 2 (use
anonymous credentials if present, otherwise use existing credentials and
do not set anon_state).  Testing of failure to get anonymous credentials
can be done through non-GSSAPI interfaces.

I am not yet sure what my preference is for gss_acquire_credentials
behavior.  Option two (get anonymous credentials either from the default
cache or in a new memory cache) sounds good on the surface.

For libkrb5, I think there should be a clearly-defined interface for
getting anonymous creds, but if that interface is not used, the library
should not make any additional effort to make things consistent.  I
don't yet have an opinion on what the anonymous API should look like.

Finally: it's my understanding (though I haven't read the anonymous
pkinit spec) that it is valid to do anonymous pkinit to a realm you
can't verify the certificate of, and that this may be valuable in
obtaining a FAST armor ticket--with the proviso that your armor is then
vulnerable to a man-in-the-middle attack.  It sounds like your
implementation is not going to allow that case at first, but the
interface should keep that case in mind as a future possibility.


_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Nicolas Williams]

On Tue, Nov 03, 2009 at 11:55:00AM -0500, Greg Hudson wrote:
> Finally: it's my understanding (though I haven't read the anonymous
> pkinit spec) that it is valid to do anonymous pkinit to a realm you
> can't verify the certificate of, and that this may be valuable in
> obtaining a FAST armor ticket--with the proviso that your armor is then
> vulnerable to a man-in-the-middle attack.  It sounds like your
> implementation is not going to allow that case at first, but the
> interface should keep that case in mind as a future possibility.

The GSS-API certainly allows the mechanism to have an anonymous name
type for acceptor naming...  This could be allowed -- it can't happen
accidentally, though it may not be very useful at all, so if Sam doesn't
want to implement it, I understand.
_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Sam Hartman]

>>>>> "Greg" == Greg Hudson <ghudson@...> writes:


    Greg> Finally: it's my understanding (though I haven't read the
    Greg> anonymous pkinit spec) that it is valid to do anonymous
    Greg> pkinit to a realm you can't verify the certificate of, and
    Greg> that this may be valuable in obtaining a FAST armor
    Greg> ticket--with the proviso that your armor is then vulnerable
    Greg> to a man-in-the-middle attack.  It sounds like your
    Greg> implementation is not going to allow that case at first, but
    Greg> the interface should keep that case in mind as a future
    Greg> possibility.

I agree the libkrb5 interface should keep that in mind.  I'm not sure
this matches the GSS-API model well enough to support there.

In particular, take a look at the requirements in
draft-ietf-krb-wg-anon-10 for the anonymous KDC case.  The text seems
to place a fairly strong requirement that you verify the KDC before
using the ticket.  So, I'm not sure it would be permitted to use it in
a normal ap exchange.  If we ignore that, then it would perhaps be
permissible to use such a ticket in gss-api with the mutual
authentication flag cleared, although you would get very different
security guarantees than you typically do with Kerberos especially if
you use per-message protection.  I'm not sure if that's OK or not.
_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Nicolas Williams]

In my interpretation, the principles of the GSS-API w.r.t. anonymity are
as follows:

 - If you use a non-default credential handle when calling
   gss_init_sec_context(), then the mechanism is constrained to
   authenticating only that handle's desired_name as the initiator
   principal, UNLESS the anon req_flag is set (more on that below).

    - If you use a credential handle for a desired_name with anonymous
      or anonymous-like name type, then you can only get anonymity (or
      pseudonymity; see below) when you call gss_init_sec_context() with
      that credential handle.

      The GSS-API doesn't have a notion of credential store or of
      "initial credentials", so it's possible that one could get
      pseudonymity instead of anonymity unless the caller sets the
      anonymous req_flag (they have to then check that it's set in the
      ret_flags).  That is, the implementation might fetch an anonymous
      TGT and then fetch service tickets using that TGT, which might
      allow all the various services to track the initiators' actions
      back to that one anon TGT.  gss_acquire_cred() could store
      credentials for anonymous desired_names in the current ccache, but
      I'd rather that it always return fresh credentials when
      desired_name is an anonymous name.

 - To use a default credential handle is the same as to use a credential
   handle whose desired_name matches the default principal of the
   current credential store (ccache).  See above.

 - req_flags are all optional; a mechanism is free to grant more or
   fewer than requested, and the caller of gss_init_sec_context() must
   check ret_flags.  However, ret_flags must be set appropriately as
   soon as possible!  RFC2743 says:

   "
   Callers wishing to perform context establishment only if anonymity
   support is provided should transfer a returned token from
   GSS_Init_sec_context() to the peer only if it is accompanied by a
   TRUE anon_state indicator.
   "

   This leaves the mechanism designer/implementor a lot of freedom.  Too
   much freedom, I think.  But not so much freedom that a careful
   application would ever authenticate a non-anon initiator
   accidentally.

   (Aside: it would be very odd to set the anonymous ret_flag when the
   caller did not request it and the initiator credential handle was not
   an anonymous one.  This should just not happen.  Note that mechanisms
   that can only do anon initiator name authentication can only have
   anon cred handles.  If you use SPNEGO, a default credential handle,
   and such a mechanism, then you could see the anon ret_flag set even
   though the caller did not set the anon req_flag.)

   Thus to call gss_init_sec_context() with the default credential when
   there's a non-anonymous crendential available, and the anonymous
   req_flag means that the mechanism is free to authenticate the
   initiator non-anonymously (and not set the anonymous ret_flag).

   Just because the mechanism can do that doesn't mean it should.  I'd
   rather treat the anon req_flag as critical in the mechanism
   implementations, even though from the application's p.o.v. it's
   optional.

We can derive these rules for the krb5 mech from the above:

1) If the app calls gss_import_name() with GSS_C_NT_ANONYMOUS to get an
   anon name, then calls gss_acquire_cred(), then for the krb5 mech that
   implements anonymous PKINIT this should work.

   We may need to define a krb5-specific anon name-type whose syntax
   allows the specification of a realm name.  But use of that should be
   optional.

2) If the app calls gss_acquire_cred() with desired_name == some
   anonymous or anonymous-like name, then the krb5 mech should acquire
   anon tickets, or defer this to the point where gss_init_sec_context()
   is called.

3) If the app calls gss_init_sec_context() with an anonymous credential
   handle then:

   a) the krb5 mech should authenticate that credential's anonymous
   desired_name and NEVER authenticate the caller's default credential's
   desired_name, if there are any non-anon default creds;

   b) the anon ret_flag should be set regardless of whether the anon
   req_flag was set.

4) If the app calls gss_init_sec_context() with a default credential, or
   with a non-anonymous credential handle *and* sets the anon req_flag,
   then technically the krb5 mech should attempt anonymous
   authentication and may fail without authenticating the non-anon
   initiator name if it could not do anonymous authentication.  Ideally
   the mechanism should attempt anon auth and must fail without
   authenticating the non-anon initiator.  (If anon auth succeeds, then
   the anon ret_flag must be set, of course.)

Nico
--
_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Nicolas Williams]

On Tue, Nov 03, 2009 at 12:37:47PM -0500, Sam Hartman wrote:

> >>>>> "Greg" == Greg Hudson <ghudson@...> writes:
>     Greg> Finally: it's my understanding (though I haven't read the
>     Greg> anonymous pkinit spec) that it is valid to do anonymous
>     Greg> pkinit to a realm you can't verify the certificate of, and
>     Greg> that this may be valuable in obtaining a FAST armor
>     Greg> ticket--with the proviso that your armor is then vulnerable
>     Greg> to a man-in-the-middle attack.  It sounds like your
>     Greg> implementation is not going to allow that case at first, but
>     Greg> the interface should keep that case in mind as a future
>     Greg> possibility.
>
> I agree the libkrb5 interface should keep that in mind.  I'm not sure
> this matches the GSS-API model well enough to support there.
>
> In particular, take a look at the requirements in
> draft-ietf-krb-wg-anon-10 for the anonymous KDC case.  The text seems
> to place a fairly strong requirement that you verify the KDC before
> using the ticket.  So, I'm not sure it would be permitted to use it in
> a normal ap exchange.  If we ignore that, then it would perhaps be
> permissible to use such a ticket in gss-api with the mutual
> authentication flag cleared, although you would get very different
> security guarantees than you typically do with Kerberos especially if
> you use per-message protection.  I'm not sure if that's OK or not.

The GSS-API very explicitly contemplates, and allows, for security
contexts with anonymous initiator and acceptor names.

Clearly such security contexts are, practiclaly by definition, subject
to MITM attacks.  But the API allows them.  One supposes that by using
extended naming APIs one could extract a realm's KDC's certificate and
then use that for SSH-style leap-of-faith authentication.  But mostly I
think this is useless.

I'm happy to have the mechanism support this, or not.  The only good
reason to not support it is that it would be wasting your time on a
useless feature (I don't see the draft-ietf-krb-wg-anon-10 requirement
as applicable to the GSS-API mechanism -- it shouldn't be, in any case).
And I see no good reasons to support it other than completeness.

(Maybe some day we'll have a reasonable use case fo SSH-style leap-of-
faith as described above.  Someone can implement this then.)

Nico
--
_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Sam Hartman]

>>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams@...> writes:

    >> I agree the libkrb5 interface should keep that in mind.  I'm
    >> not sure this matches the GSS-API model well enough to support
    >> there.
    >>
    >> In particular, take a look at the requirements in
    >> draft-ietf-krb-wg-anon-10 for the anonymous KDC case.  The text
    >> seems to place a fairly strong requirement that you verify the
    >> KDC before using the ticket.  So, I'm not sure it would be
    >> permitted to use it in a normal ap exchange.  If we ignore
    >> that, then it would perhaps be permissible to use such a ticket
    >> in gss-api with the mutual authentication flag cleared,
    >> although you would get very different security guarantees than
    >> you typically do with Kerberos especially if you use
    >> per-message protection.  I'm not sure if that's OK or not.

    Nicolas> The GSS-API very explicitly contemplates, and allows, for
    Nicolas> security contexts with anonymous initiator and acceptor
    Nicolas> names.


Really?
I was not aware that security contexts with anonymous acceptor names were permitted.
Do you have a reference handy?
_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Nicolas Williams]

On Tue, Nov 03, 2009 at 02:11:43PM -0500, Sam Hartman wrote:
>     Nicolas> The GSS-API very explicitly contemplates, and allows, for
>     Nicolas> security contexts with anonymous initiator and acceptor
>     Nicolas> names.
>
> Really?
> I was not aware that security contexts with anonymous acceptor names were permitted.
> Do you have a reference handy?

I mis-read RFC2743, section 1.2.5, page 25.  On second re-reading
RFC2743 is explicit only about initiator names as anonymous names.  But
even so, why would anonymous acceptor names not be permitted?

Nico
--
_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Jeffrey Hutzelman]

--On Tuesday, November 03, 2009 11:41:55 AM -0600 Nicolas Williams
<Nicolas.Williams@...> wrote:

>    Just because the mechanism can do that doesn't mean it should.  I'd
>    rather treat the anon req_flag as critical in the mechanism
>    implementations, even though from the application's p.o.v. it's
>    optional.

Me too.

Normally, we tell application implementors to check the return state and
not use a context that doesn't meet the application's needs; this allows
applications lots of flexibility in asking for the moon and using what they
can get.  However, anon_req is qualitatively different here, in that if you
request an anonymous context, complete context establishment, and end up
with a non-anonymous context, you've given away the farm even if you don't
use the context.  Now, we provide applications a way to prevent this by
indicating anon_state early enough that they can decline to send a token
along that would reveal the client's identity.  But, I'm inclined to think
it's better (safer) for mechanisms simply not to establish a context at all
if anonymity is requested and cannot be provided.

-- Jeff
_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Sam Hartman]

>>>>> "Jeffrey" == Jeffrey Hutzelman <jhutz@...> writes:

    Jeffrey> --On Tuesday, November 03, 2009 11:41:55 AM -0600 Nicolas
    Jeffrey> Williams
    Jeffrey> <Nicolas.Williams@...> wrote:

>    Just because the mechanism can do that doesn't mean it should.  I'd
    >> rather treat the anon req_flag as critical in the mechanism
    >> implementations, even though from the application's p.o.v. it's
    >> optional.

    Jeffrey> Me too.

    Jeffrey> Normally, we tell application implementors to check the
    Jeffrey> return state and not use a context that doesn't meet the
    Jeffrey> application's needs; this allows applications lots of
    Jeffrey> flexibility in asking for the moon and using what they
    Jeffrey> can get.  However, anon_req is qualitatively different
    Jeffrey> here, in that if you request an anonymous context,
    Jeffrey> complete context establishment, and end up with a
    Jeffrey> non-anonymous context, you've given away the farm even if
    Jeffrey> you don't use the context.  Now, we provide applications
    Jeffrey> a way to prevent this by indicating anon_state early
    Jeffrey> enough that they can decline to send a token along that
    Jeffrey> would reveal the client's identity.  But, I'm inclined to
    Jeffrey> think it's better (safer) for mechanisms simply not to
    Jeffrey> establish a context at all if anonymity is requested and
    Jeffrey> cannot be provided.

If you're going to do the work to standardize this behavior, I wouldn't mind much, although I probably would mildly disagree.

However, I disagree fairly strongly unless this is going to be
accompanied by an update to 2743.  My argument is that it breaks
conforming GSS-API applications.  If I'd prefer anonymous but would be
willing to accept an authenticated context, then I would end up
failing with your mechanism.  If I'm writing a portable application I
have to check the output flag anyway, even if some mechanisms do offer
this behavior.

So, with your approach, you complicate the life of every portable application.
That seems poor.
_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[Nicolas Williams]

On Wed, Nov 04, 2009 at 04:13:25PM -0500, Sam Hartman wrote:

> If you're going to do the work to standardize this behavior, I
> wouldn't mind much, although I probably would mildly disagree.
>
> However, I disagree fairly strongly unless this is going to be
> accompanied by an update to 2743.  My argument is that it breaks
> conforming GSS-API applications.  If I'd prefer anonymous but would be
> willing to accept an authenticated context, then I would end up
> failing with your mechanism.  If I'm writing a portable application I
> have to check the output flag anyway, even if some mechanisms do offer
> this behavior.

Interesting.  I'm not sure what the value of that is.  I suppose one
might be signing on to a comment board where one might act differently
according to whether one is anonymous, for example.

> So, with your approach, you complicate the life of every portable
> application.  That seems poor.

I don't think mechanisms are required to act as you say though.  But
yes, if there's any value to the optional anonymity, then I'd have to
agree.

I'd certainly expect apps where anonymity matters to: a) uses
GSS_C_NT_ANONYMOUS names for the initiator's credential's desired_name,
b) use the anon req_flag, c) check for the presence of the anon ret_flag
after each call to gss_init_sec_context().

Nico
--
_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev

[ghudson-2]

On Wed, 2009-11-04 at 16:13 -0500, Sam Hartman wrote:
> However, I disagree fairly strongly unless this is going to be
> accompanied by an update to 2743.  My argument is that it breaks
> conforming GSS-API applications.  If I'd prefer anonymous but would be
> willing to accept an authenticated context, then I would end up
> failing with your mechanism.  If I'm writing a portable application I
> have to check the output flag anyway, even if some mechanisms do offer
> this behavior.

I agree with Sam.  I don't see any point in providing safety that
applications can't rely on.  It seems like it would only encourage apps
to improperly rely on gss-krb5's safety and then be unsafe if used with
a different mechanism.


_______________________________________________
krbdev mailing list             krbdev@...
https://mailman.mit.edu/mailman/listinfo/krbdev