[kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

[kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

Eric Rescorla-3
This document seems generally sound. There are some things about this
API that confused/surprised me and seem perhaps unwise, but given that
this is a bis, I will mostly confine my review to mostly calling them
out and asking you to make sure I understand and that the document is
clear.

OVERALL
1. What is a fatal error?
The document describes exceptions as indicating "fatal errors".
What does this mean for the state of the context. For instance,
if I receive an exception from initSecContext(), does that mean
that it is no longer possible to initiate it? Your example code
seems to treat them as fatal for the context. What happens
if I try to use a context after such an event?


2. How do I enforce properties for received messages?
I see that I can request services for context initialization
(requestConf), and that I can check whether a given message
was encrypted (getPrivacy) but it's not clear to me if this
causes the API to enforce these rules for tokens that I
receive. Is that possible or do I just need to check?

3. Are the request* flags() hard limits? E.g., if I do
requestMutualAuth() do I get it or fail?


4. It's a little unusual to have a structure where you keep
calling initSecContext or acceptContext() repeatedly. In
most APIs you would do like "setRole(Server)" or
"setRoleClient(), and then "Handshake().



DETAIL
S 6.1.16.
Can addProviderAtFront() be used to add new providers which
the API would not normally use at all?

S 6.4.9.
   Successful completion of this call does not guarantee that wrap will
   be able to protect a message of the computed length, since this
   ability may depend on the availability of system resources at the
   time that wrap is called.  However, if the implementation itself
   imposes an upper limit on the length of messages that may be
   processed by wrap, the implementation should not return a value that
   is greater than this length.

This should seems pretty weak. This isn't a hard limit?

S 6.4.10.
   Instance of MessageProp that is used by the
   application to set the desired QOP and privacy
   state.  Set the desired QOP to 0 to request the
   default QOP.  Upon return from this method, this
   object will contain the actual privacy state that
   was applied to the message by the underlying
   mechanism.

Just to be clear: if you ask for a specific QOP you always get it
(or failure). This checking thing is only if you use 0?

It would also be helpful to point out that QOP is mech-specific
as noted in RFC 2743.



S 6.4.21.
What does requestInteg() mean? As far as I can tell the only thing
you can do with a context is wrap() or getMIC(), both of which involve
integrity. So what happens if you set it false?

S 6.5.7.
Does "privacy" here mean "confidentiality"? Can you clarify.


EDITORIAL
S 3.3.
Please do not use the phrase "cryptographic checksum", I recognize
that the terminology in this document is idiosyncratic because of
age, but this isn't really a modern term. Typically
we would now use "authentication tag" or "integrity tag"

S 4.12.3.
So an exception is thrown for an invalid token?


S 5.3.
gss_release_cred() is just eager, right? In any case the data will
be cleaned up on GC? In any case you should make this clear.

S 6.1.15.
I wouldn't say you are "creating a previously exported context". You
are either importing it or creating a new context from a previously
exported one.

S 6.2.1.

   // export and re-import the name
   byte[] exportName = mechName.export();

   // create a new name object from the exported buffer
   GSSName newName = mgr.createName(exportName,
                     GSSName.NT_EXPORT_NAME);
                     
This comment structure is confusing, because the first is just
the export. I would change that.


S 6.2.6.
It's a bit unclear to me under what circumstances you can compare GSS
names. I see you can do .equals() and export/memcmp, but can you
compare strings? Perhaps after you canonicalize them?


S 6.3.9.
Does "union over all mechanisms" mean that if mechanism A supports
INITIATE and B supports ACCEPT you get "INITIATE_AND_ACCEPT"

S 6.4.X
The presentation order here is weird because you show initSecContext()
in the 6.4.1. example but then define it in 6.4.3 and then show
another example that's reduced in 6.4.4. Perhaps you can consolidate
these?

-Ekr


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

Benjamin Kaduk
Hi Ekr,

[authors: some questions remain, inline]

On Sat, Jun 17, 2017 at 11:23:10AM -0700, Eric Rescorla wrote:
> This document seems generally sound. There are some things about this
> API that confused/surprised me and seem perhaps unwise, but given that
> this is a bis, I will mostly confine my review to mostly calling them
> out and asking you to make sure I understand and that the document is
> clear.

There are some bits of the GSSAPI that are strange, surprising, and
confusing, yes ... I hear rumors that there are ideas for a GSSAPIv3
floating around, though nothing concrete yet.

> OVERALL
> 1. What is a fatal error?

Fatal errors are specified as a specific list of GSS-API major
status codes in RFC 2743, table 1 (things like GSS_S_BAD_MIC,
GSS_S_FAILURE, GSS_S_UNAUTHORIZED, etc.), as opposed to informatory
status codes like GSS_S_COMPLETE, GSS_S_CONTINUE_NEEDED,
GSS_S_DUPLICATE_TOKEN (which is, confusingly, a fatal error during
context establishment), etc.

> The document describes exceptions as indicating "fatal errors".
> What does this mean for the state of the context. For instance,
> if I receive an exception from initSecContext(), does that mean
> that it is no longer possible to initiate it? Your example code
> seems to treat them as fatal for the context. What happens
> if I try to use a context after such an event?

I think this is also something specified at the GSS level, though
RFC 2743 is unfortunately obscure about it.  In the
context-negotiating routines (GSS_Init_sec_context() and
GSS_Accept_sec_context()), successful return codes are
GSS_S_COMPLETE and GSS_S_CONTINUE_NEEDED, and other return codes (at
the abstract GSS level) abort the context negotiation.  This is
buried in the descriptions for those two functions, though hopefully
I made it a bit more clear in RFC 7546.  (Once a context is
established, then more robust error handling is available and a
context can remain useful after a given message-handling function
returns an error/throws an exception.)  The Java bindings handle the
GSS_S_COMPLETE/GSS_S_CONTINUE_NEEDED distinction differently than
the C bindings do (with init/acceptSecContext returning the token to
send to the peer, if any, and an isEstablished() function to query
whether the local side is complete), but any other GSS-level result
from the context-establishment functions is a GSS-level error, which
presents as a java exception.  Subsequent calls on the failed context are
expected to also throw exceptions (something like the abstract GSS
API GSS_S_NO_CONTEXT).

>
> 2. How do I enforce properties for received messages?
> I see that I can request services for context initialization
> (requestConf), and that I can check whether a given message
> was encrypted (getPrivacy) but it's not clear to me if this
> causes the API to enforce these rules for tokens that I
> receive. Is that possible or do I just need to check?

I think you just need to check.
The GSSAPI is in general a request-and-check sort of affair, and
even when confidentiality protection is enabled on a given context,
a given message could be wrapped without confidentility protection.
In the abstract API, GSS_Unwrap() has an explicit conf_state output
value; the msgProp stuff is essentially specific to the Java
bindings.

> 3. Are the request* flags() hard limits? E.g., if I do
> requestMutualAuth() do I get it or fail?

They are not hard limits; this is just how the GSS-API works.
You request things but have to check whether you got them.

>
> 4. It's a little unusual to have a structure where you keep
> calling initSecContext or acceptContext() repeatedly. In
> most APIs you would do like "setRole(Server)" or
> "setRoleClient(), and then "Handshake().

Yes.
The designs floating around for a GSSAPIv3 would most likely have
such a common Handshake() API, but for v2 (and v1) we are stuck with
separtae Init and Accept roles.

>
>
> DETAIL

Now we get into areas about which I am less certain; I'll loop in
the authors alias to get a confirmation/correction.

> S 6.1.16.
> Can addProviderAtFront() be used to add new providers which
> the API would not normally use at all?

It seems likely.  In the C bindings we generally have mechanisms
globally enabled, and site-local customizations go in
/etc/gss/mechs.d .

> S 6.4.9.
>    Successful completion of this call does not guarantee that wrap will
>    be able to protect a message of the computed length, since this
>    ability may depend on the availability of system resources at the
>    time that wrap is called.  However, if the implementation itself
>    imposes an upper limit on the length of messages that may be
>    processed by wrap, the implementation should not return a value that
>    is greater than this length.
>
> This should seems pretty weak. This isn't a hard limit?

This is telling you what the ciphertext expansion is, but in reverse
-- you put in the ciphertext size and receive back a plaintext
input length that would produce that much ciphertext.

> S 6.4.10.
>    Instance of MessageProp that is used by the
>    application to set the desired QOP and privacy
>    state.  Set the desired QOP to 0 to request the
>    default QOP.  Upon return from this method, this
>    object will contain the actual privacy state that
>    was applied to the message by the underlying
>    mechanism.
>
> Just to be clear: if you ask for a specific QOP you always get it
> (or failure). This checking thing is only if you use 0?

I believe so.  GSS QOPs are for practical purposes deprecated and
everyone uses 0.

> It would also be helpful to point out that QOP is mech-specific
> as noted in RFC 2743.

Sure.  (Maybe also that their use is disrecommended or something
like that.)

>
>
> S 6.4.21.
> What does requestInteg() mean? As far as I can tell the only thing
> you can do with a context is wrap() or getMIC(), both of which involve
> integrity. So what happens if you set it false?

If you set it to false, then some (hypothetical?) mechanism that
only provides authentication could be used to establish a security
context.  There are also some other GSS functions like
GSS_Pseudo_random() (RFC 4401) that could potentially be used on a
security context that does not require per-message protections,
though I don't know of Java bindings for that one, at least.

Authentication-only is a valid workflow even just limited to this
self-contained spec, using the security context negotiation to
establish a context, query the peer's name with getSrcName(), and
make authorization decisions based on that name.

One might imagine someone trying to shoehorn OAuth2 into a GSS
mechanism using something like that.


> S 6.5.7.
> Does "privacy" here mean "confidentiality"? Can you clarify.

That's the only interpretation I can come up with that makes sense,
but let's check with the authors.

>
> EDITORIAL
> S 3.3.
> Please do not use the phrase "cryptographic checksum", I recognize
> that the terminology in this document is idiosyncratic because of
> age, but this isn't really a modern term. Typically
> we would now use "authentication tag" or "integrity tag"
>
> S 4.12.3.
> So an exception is thrown for an invalid token?

I think so.

>
> S 5.3.
> gss_release_cred() is just eager, right? In any case the data will
> be cleaned up on GC? In any case you should make this clear.

I think so, though there is an implicit recommendation to destroy
sensitive crypto material immediately after use.

> S 6.1.15.
> I wouldn't say you are "creating a previously exported context". You
> are either importing it or creating a new context from a previously
> exported one.

"importing" would be more consistent with the language used by the C
bindings.

> S 6.2.1.
>
>    // export and re-import the name
>    byte[] exportName = mechName.export();
>
>    // create a new name object from the exported buffer
>    GSSName newName = mgr.createName(exportName,
>                      GSSName.NT_EXPORT_NAME);
>
> This comment structure is confusing, because the first is just
> the export. I would change that.
>
>
> S 6.2.6.
> It's a bit unclear to me under what circumstances you can compare GSS
> names. I see you can do .equals() and export/memcmp, but can you
> compare strings? Perhaps after you canonicalize them?

You have stumbled upon one of the worst warts on the GSS-API ;)

It is confusing no matter whether you look at the abstract spec or
language bindings.  When you first create a name you end up with a
generic "internal name", and certain operations can cause that to be
transformed into a "mechanism name" that contains additional
mechanism-specific information.  The offically recommended way to
compare GSS names is to GSS_Export_name() and use memcmp(), noting
that you must GSS_Canonicalize_name() between GSS_Import_name() and
GSS_Export_name().

>From RFC 2743:

   Note that the results obtained by using GSS_Compare_name() will in
   general be different from those obtained by invoking
   GSS_Canonicalize_name() and GSS_Export_name(), and then comparing the
   exported names.  The first series of operations determines whether
   two (unauthenticated) names identify the same principal; the second
   whether a particular mechanism would authenticate them as the same
   principal.  These two operations will in general give the same
   results only for MNs.

Sadly, lots of applications use GSS_Display_name() and strcmp(),
which is something of a security vulnerability waiting to happen.

I'm not entirely sure that I've answered your question, though.



>
> S 6.3.9.
> Does "union over all mechanisms" mean that if mechanism A supports
> INITIATE and B supports ACCEPT you get "INITIATE_AND_ACCEPT"

Yes.

Again quoting RFC 2743:

   GSS_Inquire_cred() should indicate INITIATE-AND-ACCEPT for
   "cred_usage" if both of the following conditions hold:

      (1) there exists in the credential an element which allows context
      initiation using some mechanism

      (2) there exists in the credential an element which allows context
      acceptance using some mechanism (allowably, but not necessarily,
      one of the same mechanism(s) qualifying for (1)).


> S 6.4.X
> The presentation order here is weird because you show initSecContext()
> in the 6.4.1. example but then define it in 6.4.3 and then show
> another example that's reduced in 6.4.4. Perhaps you can consolidate
> these?

I'll leave that for the authors.

-Ben

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

Weijun Wang
Hi Ekr,

Thanks for the review.

Below I keep questions that I can answer. For other general GSS-API
questions, I could not answer better than Ben. Thanks a lot, Ben.

On 06/19/2017 11:41 AM, Benjamin Kaduk wrote:
> On Sat, Jun 17, 2017 at 11:23:10AM -0700, Eric Rescorla wrote:
>
>> S 6.1.16.
>> Can addProviderAtFront() be used to add new providers which
>> the API would not normally use at all?
>
> It seems likely.  In the C bindings we generally have mechanisms
> globally enabled, and site-local customizations go in
> /etc/gss/mechs.d .

Yes.

A Java security provider advertises what service(s) it provides (for
GSS-API, GssApiMechanism). If someone adds a provider that does not
contains this service, it will be ignored.

>
>> S 6.5.7.
>> Does "privacy" here mean "confidentiality"? Can you clarify.
>
> That's the only interpretation I can come up with that makes sense,
> but let's check with the authors.

Yes.

>
>>
>> EDITORIAL
>> S 3.3.
>> Please do not use the phrase "cryptographic checksum", I recognize
>> that the terminology in this document is idiosyncratic because of
>> age, but this isn't really a modern term. Typically
>> we would now use "authentication tag" or "integrity tag"

We can use "integrity tag".

>>
>> S 4.12.3.
>> So an exception is thrown for an invalid token?
>
> I think so.

Correct, if the input token is not well-formed or was not correctly
signed/encrypted by the peer, an exception will be thrown.

>
>>
>> S 5.3.
>> gss_release_cred() is just eager, right? In any case the data will
>> be cleaned up on GC? In any case you should make this clear.
>
> I think so, though there is an implicit recommendation to destroy
> sensitive crypto material immediately after use.

Well...

Java has a mechanism to provide a callback method called finalize() and
hope GC will call it, and Oracle's SunNativeGSS provider (as a bridge to
a native GSS-API lib) does provide one to release the native cred handle
explicitly. That said, everyone is saying finalize() is unreliable and
it usage is already deprecated.

Even if finalize() is reliable, whether it should dispose the cred is
not documented and up to the implementation.

>
>> S 6.1.15.
>> I wouldn't say you are "creating a previously exported context". You
>> are either importing it or creating a new context from a previously
>> exported one.
>
> "importing" would be more consistent with the language used by the C
> bindings.

Yes.

>
>> S 6.2.1.
>>
>>     // export and re-import the name
>>     byte[] exportName = mechName.export();
>>
>>     // create a new name object from the exported buffer
>>     GSSName newName = mgr.createName(exportName,
>>                       GSSName.NT_EXPORT_NAME);
>>
>> This comment structure is confusing, because the first is just
>> the export. I would change that.

Correct.

>>
>>
>> S 6.2.6.
>> It's a bit unclear to me under what circumstances you can compare GSS
>> names. I see you can do .equals() and export/memcmp, but can you
>> compare strings? Perhaps after you canonicalize them?
>
> You have stumbled upon one of the worst warts on the GSS-API ;)
>
> It is confusing no matter whether you look at the abstract spec or
> language bindings.  When you first create a name you end up with a
> generic "internal name", and certain operations can cause that to be
> transformed into a "mechanism name" that contains additional
> mechanism-specific information.  The offically recommended way to
> compare GSS names is to GSS_Export_name() and use memcmp(), noting
> that you must GSS_Canonicalize_name() between GSS_Import_name() and
> GSS_Export_name().
>
>>From RFC 2743:
>
>     Note that the results obtained by using GSS_Compare_name() will in
>     general be different from those obtained by invoking
>     GSS_Canonicalize_name() and GSS_Export_name(), and then comparing the
>     exported names.  The first series of operations determines whether
>     two (unauthenticated) names identify the same principal; the second
>     whether a particular mechanism would authenticate them as the same
>     principal.  These two operations will in general give the same
>     results only for MNs.
>
> Sadly, lots of applications use GSS_Display_name() and strcmp(),
> which is something of a security vulnerability waiting to happen.
>
> I'm not entirely sure that I've answered your question, though.

Oracle's Java implementation looks like this:

1. If they are both canonicalized, compare the canonicalized mech
element inside.

2. If only one is canonicalized, try to canonicalize the other one using
this one's mechanism, and compare the result.

3. Otherwise, canonicalize both to Kerberos 5 and compare the result.

By comparing 2 canonicalized mech elements, I mean comparing the type
and the string or byte array name, which is equivalent to comparing the
exported form.

>>
>> S 6.3.9.
>> Does "union over all mechanisms" mean that if mechanism A supports
>> INITIATE and B supports ACCEPT you get "INITIATE_AND_ACCEPT"
>
> Yes.
>
> Again quoting RFC 2743:
>
>     GSS_Inquire_cred() should indicate INITIATE-AND-ACCEPT for
>     "cred_usage" if both of the following conditions hold:
>
>        (1) there exists in the credential an element which allows context
>        initiation using some mechanism
>
>        (2) there exists in the credential an element which allows context
>        acceptance using some mechanism (allowably, but not necessarily,
>        one of the same mechanism(s) qualifying for (1)).

Same as in Java.

>
>
>> S 6.4.X
>> The presentation order here is weird because you show initSecContext()
>> in the 6.4.1. example but then define it in 6.4.3 and then show
>> another example that's reduced in 6.4.4. Perhaps you can consolidate
>> these?
>
> I'll leave that for the authors.

Yes, it's confused.

Basically, 6.4.4 and 6.4.6 are meant to demonstrate initSecContext() and
acceptSecContext(), and 6.4.1 is meant to demonstrate all methods in
GSSContext (here, from the initiator's perspective).

For this bis, I am OK with just removing 6.4.4 and 6.4.6. The examples
shown here are only of the most common usage and can be read again in S 7.

Or, we can indent 6.4.4 and 6.4.6 (plus 6.1.17 and 6.1.19) one level
deeper to become 6.4.3.1 etc and/or rename the title to "initSecContext
Example code" etc.

Or maybe the order looks weird because every class has an example as the
first sub-section (see 6.1.1, 6.2.1, and 6.3.1) before talking about
what this class is about. If this is the major reason, we can move these
examples (6.1.1, 6.2.1, 6.3.1, and 6.4.1) to the end of each section.
But then we will also need to indent/rename 6.1.17 and 6.1.19 to avoid
two "Example code" in a row.

Thanks,
Weijun

>
> -Ben
>

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

Weijun Wang
Hi Ekr

I’m about to write another version of this I-D. Except for the rearrangement of example codes in S 6, do you have any other particular parts I need to update?

Thanks
Max

> On Jun 19, 2017, at 3:52 PM, Weijun Wang <[hidden email]> wrote:
>
> Hi Ekr,
>
> Thanks for the review.
>
> Below I keep questions that I can answer. For other general GSS-API questions, I could not answer better than Ben. Thanks a lot, Ben.
>
> On 06/19/2017 11:41 AM, Benjamin Kaduk wrote:
>> On Sat, Jun 17, 2017 at 11:23:10AM -0700, Eric Rescorla wrote:
>>> S 6.1.16.
>>> Can addProviderAtFront() be used to add new providers which
>>> the API would not normally use at all?
>> It seems likely.  In the C bindings we generally have mechanisms
>> globally enabled, and site-local customizations go in
>> /etc/gss/mechs.d .
>
> Yes.
>
> A Java security provider advertises what service(s) it provides (for GSS-API, GssApiMechanism). If someone adds a provider that does not contains this service, it will be ignored.
>
>>> S 6.5.7.
>>> Does "privacy" here mean "confidentiality"? Can you clarify.
>> That's the only interpretation I can come up with that makes sense,
>> but let's check with the authors.
>
> Yes.
>
>>>
>>> EDITORIAL
>>> S 3.3.
>>> Please do not use the phrase "cryptographic checksum", I recognize
>>> that the terminology in this document is idiosyncratic because of
>>> age, but this isn't really a modern term. Typically
>>> we would now use "authentication tag" or "integrity tag"
>
> We can use "integrity tag".
>
>>>
>>> S 4.12.3.
>>> So an exception is thrown for an invalid token?
>> I think so.
>
> Correct, if the input token is not well-formed or was not correctly signed/encrypted by the peer, an exception will be thrown.
>
>>>
>>> S 5.3.
>>> gss_release_cred() is just eager, right? In any case the data will
>>> be cleaned up on GC? In any case you should make this clear.
>> I think so, though there is an implicit recommendation to destroy
>> sensitive crypto material immediately after use.
>
> Well...
>
> Java has a mechanism to provide a callback method called finalize() and hope GC will call it, and Oracle's SunNativeGSS provider (as a bridge to a native GSS-API lib) does provide one to release the native cred handle explicitly. That said, everyone is saying finalize() is unreliable and it usage is already deprecated.
>
> Even if finalize() is reliable, whether it should dispose the cred is not documented and up to the implementation.
>
>>> S 6.1.15.
>>> I wouldn't say you are "creating a previously exported context". You
>>> are either importing it or creating a new context from a previously
>>> exported one.
>> "importing" would be more consistent with the language used by the C
>> bindings.
>
> Yes.
>
>>> S 6.2.1.
>>>
>>>    // export and re-import the name
>>>    byte[] exportName = mechName.export();
>>>
>>>    // create a new name object from the exported buffer
>>>    GSSName newName = mgr.createName(exportName,
>>>                      GSSName.NT_EXPORT_NAME);
>>>
>>> This comment structure is confusing, because the first is just
>>> the export. I would change that.
>
> Correct.
>
>>>
>>>
>>> S 6.2.6.
>>> It's a bit unclear to me under what circumstances you can compare GSS
>>> names. I see you can do .equals() and export/memcmp, but can you
>>> compare strings? Perhaps after you canonicalize them?
>> You have stumbled upon one of the worst warts on the GSS-API ;)
>> It is confusing no matter whether you look at the abstract spec or
>> language bindings.  When you first create a name you end up with a
>> generic "internal name", and certain operations can cause that to be
>> transformed into a "mechanism name" that contains additional
>> mechanism-specific information.  The offically recommended way to
>> compare GSS names is to GSS_Export_name() and use memcmp(), noting
>> that you must GSS_Canonicalize_name() between GSS_Import_name() and
>> GSS_Export_name().
>>> From RFC 2743:
>>    Note that the results obtained by using GSS_Compare_name() will in
>>    general be different from those obtained by invoking
>>    GSS_Canonicalize_name() and GSS_Export_name(), and then comparing the
>>    exported names.  The first series of operations determines whether
>>    two (unauthenticated) names identify the same principal; the second
>>    whether a particular mechanism would authenticate them as the same
>>    principal.  These two operations will in general give the same
>>    results only for MNs.
>> Sadly, lots of applications use GSS_Display_name() and strcmp(),
>> which is something of a security vulnerability waiting to happen.
>> I'm not entirely sure that I've answered your question, though.
>
> Oracle's Java implementation looks like this:
>
> 1. If they are both canonicalized, compare the canonicalized mech element inside.
>
> 2. If only one is canonicalized, try to canonicalize the other one using this one's mechanism, and compare the result.
>
> 3. Otherwise, canonicalize both to Kerberos 5 and compare the result.
>
> By comparing 2 canonicalized mech elements, I mean comparing the type and the string or byte array name, which is equivalent to comparing the exported form.
>
>>>
>>> S 6.3.9.
>>> Does "union over all mechanisms" mean that if mechanism A supports
>>> INITIATE and B supports ACCEPT you get "INITIATE_AND_ACCEPT"
>> Yes.
>> Again quoting RFC 2743:
>>    GSS_Inquire_cred() should indicate INITIATE-AND-ACCEPT for
>>    "cred_usage" if both of the following conditions hold:
>>       (1) there exists in the credential an element which allows context
>>       initiation using some mechanism
>>       (2) there exists in the credential an element which allows context
>>       acceptance using some mechanism (allowably, but not necessarily,
>>       one of the same mechanism(s) qualifying for (1)).
>
> Same as in Java.
>
>>> S 6.4.X
>>> The presentation order here is weird because you show initSecContext()
>>> in the 6.4.1. example but then define it in 6.4.3 and then show
>>> another example that's reduced in 6.4.4. Perhaps you can consolidate
>>> these?
>> I'll leave that for the authors.
>
> Yes, it's confused.
>
> Basically, 6.4.4 and 6.4.6 are meant to demonstrate initSecContext() and acceptSecContext(), and 6.4.1 is meant to demonstrate all methods in GSSContext (here, from the initiator's perspective).
>
> For this bis, I am OK with just removing 6.4.4 and 6.4.6. The examples shown here are only of the most common usage and can be read again in S 7.
>
> Or, we can indent 6.4.4 and 6.4.6 (plus 6.1.17 and 6.1.19) one level deeper to become 6.4.3.1 etc and/or rename the title to "initSecContext Example code" etc.
>
> Or maybe the order looks weird because every class has an example as the first sub-section (see 6.1.1, 6.2.1, and 6.3.1) before talking about what this class is about. If this is the major reason, we can move these examples (6.1.1, 6.2.1, 6.3.1, and 6.4.1) to the end of each section. But then we will also need to indent/rename 6.1.17 and 6.1.19 to avoid two "Example code" in a row.
>
> Thanks,
> Weijun
>
>> -Ben

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

Eric Rescorla-3
Well, anything where I had a question probably needs some clarifying text.

-Ekr


On Fri, Jul 7, 2017 at 1:15 AM, Weijun Wang <[hidden email]> wrote:
Hi Ekr

I’m about to write another version of this I-D. Except for the rearrangement of example codes in S 6, do you have any other particular parts I need to update?

Thanks
Max

> On Jun 19, 2017, at 3:52 PM, Weijun Wang <[hidden email]> wrote:
>
> Hi Ekr,
>
> Thanks for the review.
>
> Below I keep questions that I can answer. For other general GSS-API questions, I could not answer better than Ben. Thanks a lot, Ben.
>
> On 06/19/2017 11:41 AM, Benjamin Kaduk wrote:
>> On Sat, Jun 17, 2017 at 11:23:10AM -0700, Eric Rescorla wrote:
>>> S 6.1.16.
>>> Can addProviderAtFront() be used to add new providers which
>>> the API would not normally use at all?
>> It seems likely.  In the C bindings we generally have mechanisms
>> globally enabled, and site-local customizations go in
>> /etc/gss/mechs.d .
>
> Yes.
>
> A Java security provider advertises what service(s) it provides (for GSS-API, GssApiMechanism). If someone adds a provider that does not contains this service, it will be ignored.
>
>>> S 6.5.7.
>>> Does "privacy" here mean "confidentiality"? Can you clarify.
>> That's the only interpretation I can come up with that makes sense,
>> but let's check with the authors.
>
> Yes.
>
>>>
>>> EDITORIAL
>>> S 3.3.
>>> Please do not use the phrase "cryptographic checksum", I recognize
>>> that the terminology in this document is idiosyncratic because of
>>> age, but this isn't really a modern term. Typically
>>> we would now use "authentication tag" or "integrity tag"
>
> We can use "integrity tag".
>
>>>
>>> S 4.12.3.
>>> So an exception is thrown for an invalid token?
>> I think so.
>
> Correct, if the input token is not well-formed or was not correctly signed/encrypted by the peer, an exception will be thrown.
>
>>>
>>> S 5.3.
>>> gss_release_cred() is just eager, right? In any case the data will
>>> be cleaned up on GC? In any case you should make this clear.
>> I think so, though there is an implicit recommendation to destroy
>> sensitive crypto material immediately after use.
>
> Well...
>
> Java has a mechanism to provide a callback method called finalize() and hope GC will call it, and Oracle's SunNativeGSS provider (as a bridge to a native GSS-API lib) does provide one to release the native cred handle explicitly. That said, everyone is saying finalize() is unreliable and it usage is already deprecated.
>
> Even if finalize() is reliable, whether it should dispose the cred is not documented and up to the implementation.
>
>>> S 6.1.15.
>>> I wouldn't say you are "creating a previously exported context". You
>>> are either importing it or creating a new context from a previously
>>> exported one.
>> "importing" would be more consistent with the language used by the C
>> bindings.
>
> Yes.
>
>>> S 6.2.1.
>>>
>>>    // export and re-import the name
>>>    byte[] exportName = mechName.export();
>>>
>>>    // create a new name object from the exported buffer
>>>    GSSName newName = mgr.createName(exportName,
>>>                      GSSName.NT_EXPORT_NAME);
>>>
>>> This comment structure is confusing, because the first is just
>>> the export. I would change that.
>
> Correct.
>
>>>
>>>
>>> S 6.2.6.
>>> It's a bit unclear to me under what circumstances you can compare GSS
>>> names. I see you can do .equals() and export/memcmp, but can you
>>> compare strings? Perhaps after you canonicalize them?
>> You have stumbled upon one of the worst warts on the GSS-API ;)
>> It is confusing no matter whether you look at the abstract spec or
>> language bindings.  When you first create a name you end up with a
>> generic "internal name", and certain operations can cause that to be
>> transformed into a "mechanism name" that contains additional
>> mechanism-specific information.  The offically recommended way to
>> compare GSS names is to GSS_Export_name() and use memcmp(), noting
>> that you must GSS_Canonicalize_name() between GSS_Import_name() and
>> GSS_Export_name().
>>> From RFC 2743:
>>    Note that the results obtained by using GSS_Compare_name() will in
>>    general be different from those obtained by invoking
>>    GSS_Canonicalize_name() and GSS_Export_name(), and then comparing the
>>    exported names.  The first series of operations determines whether
>>    two (unauthenticated) names identify the same principal; the second
>>    whether a particular mechanism would authenticate them as the same
>>    principal.  These two operations will in general give the same
>>    results only for MNs.
>> Sadly, lots of applications use GSS_Display_name() and strcmp(),
>> which is something of a security vulnerability waiting to happen.
>> I'm not entirely sure that I've answered your question, though.
>
> Oracle's Java implementation looks like this:
>
> 1. If they are both canonicalized, compare the canonicalized mech element inside.
>
> 2. If only one is canonicalized, try to canonicalize the other one using this one's mechanism, and compare the result.
>
> 3. Otherwise, canonicalize both to Kerberos 5 and compare the result.
>
> By comparing 2 canonicalized mech elements, I mean comparing the type and the string or byte array name, which is equivalent to comparing the exported form.
>
>>>
>>> S 6.3.9.
>>> Does "union over all mechanisms" mean that if mechanism A supports
>>> INITIATE and B supports ACCEPT you get "INITIATE_AND_ACCEPT"
>> Yes.
>> Again quoting RFC 2743:
>>    GSS_Inquire_cred() should indicate INITIATE-AND-ACCEPT for
>>    "cred_usage" if both of the following conditions hold:
>>       (1) there exists in the credential an element which allows context
>>       initiation using some mechanism
>>       (2) there exists in the credential an element which allows context
>>       acceptance using some mechanism (allowably, but not necessarily,
>>       one of the same mechanism(s) qualifying for (1)).
>
> Same as in Java.
>
>>> S 6.4.X
>>> The presentation order here is weird because you show initSecContext()
>>> in the 6.4.1. example but then define it in 6.4.3 and then show
>>> another example that's reduced in 6.4.4. Perhaps you can consolidate
>>> these?
>> I'll leave that for the authors.
>
> Yes, it's confused.
>
> Basically, 6.4.4 and 6.4.6 are meant to demonstrate initSecContext() and acceptSecContext(), and 6.4.1 is meant to demonstrate all methods in GSSContext (here, from the initiator's perspective).
>
> For this bis, I am OK with just removing 6.4.4 and 6.4.6. The examples shown here are only of the most common usage and can be read again in S 7.
>
> Or, we can indent 6.4.4 and 6.4.6 (plus 6.1.17 and 6.1.19) one level deeper to become 6.4.3.1 etc and/or rename the title to "initSecContext Example code" etc.
>
> Or maybe the order looks weird because every class has an example as the first sub-section (see 6.1.1, 6.2.1, and 6.3.1) before talking about what this class is about. If this is the major reason, we can move these examples (6.1.1, 6.2.1, 6.3.1, and 6.4.1) to the end of each section. But then we will also need to indent/rename 6.1.17 and 6.1.19 to avoid two "Example code" in a row.
>
> Thanks,
> Weijun
>
>> -Ben



_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

Weijun Wang
In reply to this post by Eric Rescorla-3
Hi Ekr

Please read my answers below to your original questions.

> On Jun 18, 2017, at 2:23 AM, Eric Rescorla <[hidden email]> wrote:
>
> This document seems generally sound. There are some things about this
> API that confused/surprised me and seem perhaps unwise, but given that
> this is a bis, I will mostly confine my review to mostly calling them
> out and asking you to make sure I understand and that the document is
> clear.
>
> OVERALL
> 1. What is a fatal error?
> The document describes exceptions as indicating "fatal errors".
> What does this mean for the state of the context. For instance,
> if I receive an exception from initSecContext(), does that mean
> that it is no longer possible to initiate it? Your example code
> seems to treat them as fatal for the context. What happens
> if I try to use a context after such an event?

I’ll add a paragraph in "5.12.  Error Reporting” explaining whether the context is useable after an exception is thrown, for context establishment and per-message calls, respectively. Something like

+If an exception is thrown during context establishment, the context
+negotiation has failed and the GSSContext object must be abandoned.
+If it is thrown in a per-message call, the context can remain useful.

>
>
> 2. How do I enforce properties for received messages?
> I see that I can request services for context initialization
> (requestConf), and that I can check whether a given message
> was encrypted (getPrivacy) but it's not clear to me if this
> causes the API to enforce these rules for tokens that I
> receive. Is that possible or do I just need to check?

You would have to check. Even if an established security context already has its getConfState() being true, one can still wrap a message with privacy state set to false and the peer will unwrap it with success. If the peer insists only encrypted messages are allowed, she should always check.

This is already documented in 6.4.10.

>
> 3. Are the request* flags() hard limits? E.g., if I do
> requestMutualAuth() do I get it or fail?

The method does not fail itself (i.e. does not throws an exception) and you need to check the result with those getXyzState() methods after the context is established.

I can add a paragraph in S 5.9, something like:

+If any retrieved attribute does not match the desired value
+but it is necessary for the application protocol, the application should
+destroy the security context and not use it for application traffic.
+Otherwise, at this point, the context can be used by the application to
+apply cryptographic services to its data.

>
> 4. It's a little unusual to have a structure where you keep
> calling initSecContext or acceptContext() repeatedly. In
> most APIs you would do like "setRole(Server)" or
> "setRoleClient(), and then "Handshake().

Sorry but this is how GSS-API works now.

>
> DETAIL
> S 6.1.16.
> Can addProviderAtFront() be used to add new providers which
> the API would not normally use at all?

No, 6.1.16 already had

   Only when the indicated provider does not support
   the needed mechanism should the GSSManager move on to a different
   provider.

I think this implies that a new provider added might be used at all.

>
> S 6.4.9.
>    Successful completion of this call does not guarantee that wrap will
>    be able to protect a message of the computed length, since this
>    ability may depend on the availability of system resources at the
>    time that wrap is called.  However, if the implementation itself
>    imposes an upper limit on the length of messages that may be
>    processed by wrap, the implementation should not return a value that
>    is greater than this length.
>
> This should seems pretty weak. This isn't a hard limit?

I think Ben explained this perfectly. This method is mainly used to calculate the source data size limit when you have a output token size limit.

>
> S 6.4.10.
>    Instance of MessageProp that is used by the
>    application to set the desired QOP and privacy
>    state.  Set the desired QOP to 0 to request the
>    default QOP.  Upon return from this method, this
>    object will contain the actual privacy state that
>    was applied to the message by the underlying
>    mechanism.
>
> Just to be clear: if you ask for a specific QOP you always get it
> (or failure). This checking thing is only if you use 0?

Correct.

>
> It would also be helpful to point out that QOP is mech-specific
> as noted in RFC 2743.

I’ll add a line saying "QOP is an integer defined by a mechanism".

>
>
> S 6.4.21.
> What does requestInteg() mean? As far as I can tell the only thing
> you can do with a context is wrap() or getMIC(), both of which involve
> integrity. So what happens if you set it false?

Ben explained it perfectly. Sometimes a mechanism only support authentication but not secure communication.

>
> S 6.5.7.
> Does "privacy" here mean "confidentiality"? Can you clarify.

I’ll add a line in 3.5 Confidentiality saying something like “Confidentiality will be applied if the privacy state is set to true". Please forgive me I don’t want to alter the text in S 6 a lot because those were copied as doc comment in implementations and I don’t want them modified.

>
>
> EDITORIAL
> S 3.3.
> Please do not use the phrase "cryptographic checksum", I recognize
> that the terminology in this document is idiosyncratic because of
> age, but this isn't really a modern term. Typically
> we would now use "authentication tag" or "integrity tag”

GSS-API is still using the Checksum word everywhere (RFC 3961’s title is “Encryption and Checksum Specifications for Kerberos 5"). I think the cryptographic word is added like we used in cryptographic random number generator, which means it’s stronger than CRC etc. I would like to continue using this word.

>
> S 4.12.3.
> So an exception is thrown for an invalid token?

Yes, specifically, DEFECTIVE_TOKEN as defined in 4.12.1.

S 6 has not spelt all possible GSSExceptions that a method might throw for brevity.

>
> S 5.3.
> gss_release_cred() is just eager, right? In any case the data will
> be cleaned up on GC? In any case you should make this clear.

gss_release_cred() is eager, and there is no other guarantee the data can be automatically cleaned up. Even if GC cleaned up the GSSCredential object, there might be unreleased handles underneath.

S 6.3 already has

   When the credential is no longer needed, the application should call the dispose (equivalent to gss_release_cred) method to release any resources held by the credential object and to destroy any cryptographically sensitive information.

Do you think it’s necessary to append something like “An implementation should not rely on garbage control or a finalize() method to dispose a credential”?

>
> S 6.1.15.
> I wouldn't say you are "creating a previously exported context". You
> are either importing it or creating a new context from a previously
> exported one.

Accepted.

>
> S 6.2.1.
>
>    // export and re-import the name
>    byte[] exportName = mechName.export();
>
>    // create a new name object from the exported buffer
>    GSSName newName = mgr.createName(exportName,
>                      GSSName.NT_EXPORT_NAME);
>                      
> This comment structure is confusing, because the first is just
> the export. I would change that.

Accepted.

>
>
> S 6.2.6.
> It's a bit unclear to me under what circumstances you can compare GSS
> names. I see you can do .equals() and export/memcmp, but can you
> compare strings? Perhaps after you canonicalize them?

As Ben and I explained this is quite complicated. Can we not touch it in this bis?

>
> S 6.3.9.
> Does "union over all mechanisms" mean that if mechanism A supports
> INITIATE and B supports ACCEPT you get “INITIATE_AND_ACCEPT"

I’ll add some explanation:

+Specifically, GSSCredential.INITIATE_AND_ACCEPT(0) should be returned
+as long as there exists one credential element allowing context initiation
+and one credential element allowing context acceptance. These two credential
+elements are not necessarily the same one, nor do they need to use the
+same mechanism(s).

>
> S 6.4.X
> The presentation order here is weird because you show initSecContext()
> in the 6.4.1. example but then define it in 6.4.3 and then show
> another example that's reduced in 6.4.4. Perhaps you can consolidate
> these?

I’ll remove the current 6.4.2 and 6.4.4. I’ll move the examples for each class to the end of each sub-section.

Thanks
Max

>
> -Ekr
>
> _______________________________________________
> Kitten mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

Eric Rescorla-3


On Wed, Jul 12, 2017 at 8:41 PM, Weijun Wang <[hidden email]> wrote:
Hi Ekr

Please read my answers below to your original questions.

> On Jun 18, 2017, at 2:23 AM, Eric Rescorla <[hidden email]> wrote:
>
> This document seems generally sound. There are some things about this
> API that confused/surprised me and seem perhaps unwise, but given that
> this is a bis, I will mostly confine my review to mostly calling them
> out and asking you to make sure I understand and that the document is
> clear.
>
> OVERALL
> 1. What is a fatal error?
> The document describes exceptions as indicating "fatal errors".
> What does this mean for the state of the context. For instance,
> if I receive an exception from initSecContext(), does that mean
> that it is no longer possible to initiate it? Your example code
> seems to treat them as fatal for the context. What happens
> if I try to use a context after such an event?

I’ll add a paragraph in "5.12.  Error Reporting” explaining whether the context is useable after an exception is thrown, for context establishment and per-message calls, respectively. Something like

+If an exception is thrown during context establishment, the context
+negotiation has failed and the GSSContext object must be abandoned.
+If it is thrown in a per-message call, the context can remain useful.

>
>
> 2. How do I enforce properties for received messages?
> I see that I can request services for context initialization
> (requestConf), and that I can check whether a given message
> was encrypted (getPrivacy) but it's not clear to me if this
> causes the API to enforce these rules for tokens that I
> receive. Is that possible or do I just need to check?

You would have to check. Even if an established security context already has its getConfState() being true, one can still wrap a message with privacy state set to false and the peer will unwrap it with success. If the peer insists only encrypted messages are allowed, she should always check.

This is already documented in 6.4.10.

>
> 3. Are the request* flags() hard limits? E.g., if I do
> requestMutualAuth() do I get it or fail?

The method does not fail itself (i.e. does not throws an exception) and you need to check the result with those getXyzState() methods after the context is established.

I can add a paragraph in S 5.9, something like:

+If any retrieved attribute does not match the desired value
+but it is necessary for the application protocol, the application should
+destroy the security context and not use it for application traffic.
+Otherwise, at this point, the context can be used by the application to
+apply cryptographic services to its data.

Sorry, I mean does the handshake fail? Or do you just hace to check. 


> 4. It's a little unusual to have a structure where you keep
> calling initSecContext or acceptContext() repeatedly. In
> most APIs you would do like "setRole(Server)" or
> "setRoleClient(), and then "Handshake().

Sorry but this is how GSS-API works now.

>
> DETAIL
> S 6.1.16.
> Can addProviderAtFront() be used to add new providers which
> the API would not normally use at all?

No, 6.1.16 already had

   Only when the indicated provider does not support
   the needed mechanism should the GSSManager move on to a different
   provider.

I think this implies that a new provider added might be used at all.

That doesn't seem very clear to me. My point is you might have defaults and then add new omnes.

 
> EDITORIAL
> S 3.3.
> Please do not use the phrase "cryptographic checksum", I recognize
> that the terminology in this document is idiosyncratic because of
> age, but this isn't really a modern term. Typically
> we would now use "authentication tag" or "integrity tag”

GSS-API is still using the Checksum word everywhere (RFC 3961’s title is “Encryption and Checksum Specifications for Kerberos 5"). I think the cryptographic word is added like we used in cryptographic random number generator, which means it’s stronger than CRC etc. I would like to continue using this word.

At least add a parenthetical, or som other note, because this is not a term others can understand. 


>
> S 5.3.
> gss_release_cred() is just eager, right? In any case the data will
> be cleaned up on GC? In any case you should make this clear.

gss_release_cred() is eager, and there is no other guarantee the data can be automatically cleaned up. Even if GC cleaned up the GSSCredential object, there might be unreleased handles underneath.

S 6.3 already has

   When the credential is no longer needed, the application should call the dispose (equivalent to gss_release_cred) method to release any resources held by the credential object and to destroy any cryptographically sensitive information.

Do you think it’s necessary to append something like “An implementation should not rely on garbage control or a finalize() method to dispose a credential”?

Yes.



>
> S 6.1.15.
> I wouldn't say you are "creating a previously exported context". You
> are either importing it or creating a new context from a previously
> exported one.

Accepted.

>
> S 6.2.1.
>
>    // export and re-import the name
>    byte[] exportName = mechName.export();
>
>    // create a new name object from the exported buffer
>    GSSName newName = mgr.createName(exportName,
>                      GSSName.NT_EXPORT_NAME);
>
> This comment structure is confusing, because the first is just
> the export. I would change that.

Accepted.

>
>
> S 6.2.6.
> It's a bit unclear to me under what circumstances you can compare GSS
> names. I see you can do .equals() and export/memcmp, but can you
> compare strings? Perhaps after you canonicalize them?

As Ben and I explained this is quite complicated. Can we not touch it in this bis?

The fact that it's complicated seems like more reason to explain it.

-Ekr


>
> S 6.3.9.
> Does "union over all mechanisms" mean that if mechanism A supports
> INITIATE and B supports ACCEPT you get “INITIATE_AND_ACCEPT"

I’ll add some explanation:

+Specifically, GSSCredential.INITIATE_AND_ACCEPT(0) should be returned
+as long as there exists one credential element allowing context initiation
+and one credential element allowing context acceptance. These two credential
+elements are not necessarily the same one, nor do they need to use the
+same mechanism(s).

>
> S 6.4.X
> The presentation order here is weird because you show initSecContext()
> in the 6.4.1. example but then define it in 6.4.3 and then show
> another example that's reduced in 6.4.4. Perhaps you can consolidate
> these?

I’ll remove the current 6.4.2 and 6.4.4. I’ll move the examples for each class to the end of each sub-section.

Thanks
Max

>
> -Ekr
>
> _______________________________________________
> Kitten mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten



_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

Weijun Wang
Hi Eric

I’ll be vacation for the next 2 weeks and I will work on the update when I’m back.

Thanks
Max

> On Jul 14, 2017, at 11:57 PM, Eric Rescorla <[hidden email]> wrote:
...
_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

Benjamin Kaduk
In reply to this post by Eric Rescorla-3
On Fri, Jul 14, 2017 at 08:57:32AM -0700, Eric Rescorla wrote:

> On Wed, Jul 12, 2017 at 8:41 PM, Weijun Wang <[hidden email]> wrote:
>
> > Hi Ekr
> >
> > Please read my answers below to your original questions.
> >
> > > On Jun 18, 2017, at 2:23 AM, Eric Rescorla <[hidden email]> wrote:
> > >
> > > This document seems generally sound. There are some things about this
> > > API that confused/surprised me and seem perhaps unwise, but given that
> > > this is a bis, I will mostly confine my review to mostly calling them
> > > out and asking you to make sure I understand and that the document is
> > > clear.
> > >
> > > OVERALL
> > > 1. What is a fatal error?
> > > The document describes exceptions as indicating "fatal errors".
> > > What does this mean for the state of the context. For instance,
> > > if I receive an exception from initSecContext(), does that mean
> > > that it is no longer possible to initiate it? Your example code
> > > seems to treat them as fatal for the context. What happens
> > > if I try to use a context after such an event?
> >
> > I’ll add a paragraph in "5.12.  Error Reporting” explaining whether the
> > context is useable after an exception is thrown, for context establishment
> > and per-message calls, respectively. Something like
> >
> > +If an exception is thrown during context establishment, the context
> > +negotiation has failed and the GSSContext object must be abandoned.
> > +If it is thrown in a per-message call, the context can remain useful.
> >
> > >
> > >
> > > 2. How do I enforce properties for received messages?
> > > I see that I can request services for context initialization
> > > (requestConf), and that I can check whether a given message
> > > was encrypted (getPrivacy) but it's not clear to me if this
> > > causes the API to enforce these rules for tokens that I
> > > receive. Is that possible or do I just need to check?
> >
> > You would have to check. Even if an established security context already
> > has its getConfState() being true, one can still wrap a message with
> > privacy state set to false and the peer will unwrap it with success. If the
> > peer insists only encrypted messages are allowed, she should always check.
> >
> > This is already documented in 6.4.10.
> >
> > >
> > > 3. Are the request* flags() hard limits? E.g., if I do
> > > requestMutualAuth() do I get it or fail?
> >
> > The method does not fail itself (i.e. does not throws an exception) and
> > you need to check the result with those getXyzState() methods after the
> > context is established.
> >
> > I can add a paragraph in S 5.9, something like:
> >
> > +If any retrieved attribute does not match the desired value
> > +but it is necessary for the application protocol, the application should
> > +destroy the security context and not use it for application traffic.
> > +Otherwise, at this point, the context can be used by the application to
> > +apply cryptographic services to its data.
> >
>
> Sorry, I mean does the handshake fail? Or do you just hace to check.

You have to check.  The GSS-API has always been a request-and-check
type of API.

>
> > 4. It's a little unusual to have a structure where you keep
> > > calling initSecContext or acceptContext() repeatedly. In
> > > most APIs you would do like "setRole(Server)" or
> > > "setRoleClient(), and then "Handshake().
> >
> > Sorry but this is how GSS-API works now.
> >
> > >
> > > DETAIL
> > > S 6.1.16.
> > > Can addProviderAtFront() be used to add new providers which
> > > the API would not normally use at all?
> >
> > No, 6.1.16 already had
> >
> >    Only when the indicated provider does not support
> >    the needed mechanism should the GSSManager move on to a different
> >    provider.
> >
> > I think this implies that a new provider added might be used at all.
> >
>
> That doesn't seem very clear to me. My point is you might have defaults and
> then add new omnes.

I think you could use this to slot in your custom provider that was not
part of the system Java implementation, yes.
But I don't interact with the Java GSS stuff very much.


> > > EDITORIAL
> > > S 3.3.
> > > Please do not use the phrase "cryptographic checksum", I recognize
> > > that the terminology in this document is idiosyncratic because of
> > > age, but this isn't really a modern term. Typically
> > > we would now use "authentication tag" or "integrity tag”
> >
> > GSS-API is still using the Checksum word everywhere (RFC 3961’s title is
> > “Encryption and Checksum Specifications for Kerberos 5"). I think the
> > cryptographic word is added like we used in cryptographic random number
> > generator, which means it’s stronger than CRC etc. I would like to continue
> > using this word.
> >
>
> At least add a parenthetical, or som other note, because this is not a term
> others can understand.

I agree; it's probably worth putting in a "(authentication tag)"
parenthetical.  (The parallel to a Kerberos Checksum remains only a
parallel, as Kerberos is only one of many GSS mechanisms.)


> > > S 5.3.
> > > gss_release_cred() is just eager, right? In any case the data will
> > > be cleaned up on GC? In any case you should make this clear.
> >
> > gss_release_cred() is eager, and there is no other guarantee the data can
> > be automatically cleaned up. Even if GC cleaned up the GSSCredential
> > object, there might be unreleased handles underneath.
> >
> > S 6.3 already has
> >
> >    When the credential is no longer needed, the application should call
> > the dispose (equivalent to gss_release_cred) method to release any
> > resources held by the credential object and to destroy any
> > cryptographically sensitive information.
> >
> > Do you think it’s necessary to append something like “An implementation
> > should not rely on garbage control or a finalize() method to dispose a
> > credential”?
> >
>
> Yes.
>
>
>
> >
> > > S 6.1.15.
> > > I wouldn't say you are "creating a previously exported context". You
> > > are either importing it or creating a new context from a previously
> > > exported one.
> >
> > Accepted.
> >
> > >
> > > S 6.2.1.
> > >
> > >    // export and re-import the name
> > >    byte[] exportName = mechName.export();
> > >
> > >    // create a new name object from the exported buffer
> > >    GSSName newName = mgr.createName(exportName,
> > >                      GSSName.NT_EXPORT_NAME);
> > >
> > > This comment structure is confusing, because the first is just
> > > the export. I would change that.
> >
> > Accepted.
> >
> > >
> > >
> > > S 6.2.6.
> > > It's a bit unclear to me under what circumstances you can compare GSS
> > > names. I see you can do .equals() and export/memcmp, but can you
> > > compare strings? Perhaps after you canonicalize them?
> >
> > As Ben and I explained this is quite complicated. Can we not touch it in
> > this bis?
>
>
> The fact that it's complicated seems like more reason to explain it.

In some sense, you can always compare GSS names (in that the compare-name
function will not throw an exception), but the results may not always
match the expected behavior.  (It's too bad that RFC 6680 didn't take the
time to summarize the state of affairs when adding naming extensions.)
I don't think we should try to provide a comprehensive review of the
state of affairs in this document, nor any normative statements (that would
only apply to implementations of the Java bindings whereas the issues
apply to all GSS-API implementations).  But perhaps something like the
following would be reasonable:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

A full treatment of the behavior of GSS name comparison is outside the
scope of this work.  However, applications should note that to avoid
surpising behavior, it is best to ensure that the names being compared
are either both mechanism names for the same mechanism, or both internal
names that are not mechanism names.  This holds whether the .equals()
method is used directly, or the .export() method is used to generate byte
strings that are then compared byte-by-byte.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

I considered adding a note that using .toString() and strcmp is
not recommended, but I do not think there is a non-normative statement
to be made that still provides value, and the lack of mention in the
text supplys a small disincentive to do so.

-Ben

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

Eric Rescorla-3


On Mon, Jul 17, 2017 at 5:22 PM, Benjamin Kaduk <[hidden email]> wrote:
On Fri, Jul 14, 2017 at 08:57:32AM -0700, Eric Rescorla wrote:
> On Wed, Jul 12, 2017 at 8:41 PM, Weijun Wang <[hidden email]> wrote:
>
> > Hi Ekr
> >
> > Please read my answers below to your original questions.
> >
> > > On Jun 18, 2017, at 2:23 AM, Eric Rescorla <[hidden email]> wrote:
> > >
> > > This document seems generally sound. There are some things about this
> > > API that confused/surprised me and seem perhaps unwise, but given that
> > > this is a bis, I will mostly confine my review to mostly calling them
> > > out and asking you to make sure I understand and that the document is
> > > clear.
> > >
> > > OVERALL
> > > 1. What is a fatal error?
> > > The document describes exceptions as indicating "fatal errors".
> > > What does this mean for the state of the context. For instance,
> > > if I receive an exception from initSecContext(), does that mean
> > > that it is no longer possible to initiate it? Your example code
> > > seems to treat them as fatal for the context. What happens
> > > if I try to use a context after such an event?
> >
> > I’ll add a paragraph in "5.12.  Error Reporting” explaining whether the
> > context is useable after an exception is thrown, for context establishment
> > and per-message calls, respectively. Something like
> >
> > +If an exception is thrown during context establishment, the context
> > +negotiation has failed and the GSSContext object must be abandoned.
> > +If it is thrown in a per-message call, the context can remain useful.
> >
> > >
> > >
> > > 2. How do I enforce properties for received messages?
> > > I see that I can request services for context initialization
> > > (requestConf), and that I can check whether a given message
> > > was encrypted (getPrivacy) but it's not clear to me if this
> > > causes the API to enforce these rules for tokens that I
> > > receive. Is that possible or do I just need to check?
> >
> > You would have to check. Even if an established security context already
> > has its getConfState() being true, one can still wrap a message with
> > privacy state set to false and the peer will unwrap it with success. If the
> > peer insists only encrypted messages are allowed, she should always check.
> >
> > This is already documented in 6.4.10.
> >
> > >
> > > 3. Are the request* flags() hard limits? E.g., if I do
> > > requestMutualAuth() do I get it or fail?
> >
> > The method does not fail itself (i.e. does not throws an exception) and
> > you need to check the result with those getXyzState() methods after the
> > context is established.
> >
> > I can add a paragraph in S 5.9, something like:
> >
> > +If any retrieved attribute does not match the desired value
> > +but it is necessary for the application protocol, the application should
> > +destroy the security context and not use it for application traffic.
> > +Otherwise, at this point, the context can be used by the application to
> > +apply cryptographic services to its data.
> >
>
> Sorry, I mean does the handshake fail? Or do you just hace to check.

You have to check.  The GSS-API has always been a request-and-check
type of API.

OK. I think that should be explicitly stated.
 

>
> > 4. It's a little unusual to have a structure where you keep
> > > calling initSecContext or acceptContext() repeatedly. In
> > > most APIs you would do like "setRole(Server)" or
> > > "setRoleClient(), and then "Handshake().
> >
> > Sorry but this is how GSS-API works now.
> >
> > >
> > > DETAIL
> > > S 6.1.16.
> > > Can addProviderAtFront() be used to add new providers which
> > > the API would not normally use at all?
> >
> > No, 6.1.16 already had
> >
> >    Only when the indicated provider does not support
> >    the needed mechanism should the GSSManager move on to a different
> >    provider.
> >
> > I think this implies that a new provider added might be used at all.
> >
>
> That doesn't seem very clear to me. My point is you might have defaults and
> then add new omnes.

I think you could use this to slot in your custom provider that was not
part of the system Java implementation, yes.
But I don't interact with the Java GSS stuff very much.

OK. This also needs to be explicit. 

> > > S 5.3.
> > > gss_release_cred() is just eager, right? In any case the data will
> > > be cleaned up on GC? In any case you should make this clear.
> >
> > gss_release_cred() is eager, and there is no other guarantee the data can
> > be automatically cleaned up. Even if GC cleaned up the GSSCredential
> > object, there might be unreleased handles underneath.
> >
> > S 6.3 already has
> >
> >    When the credential is no longer needed, the application should call
> > the dispose (equivalent to gss_release_cred) method to release any
> > resources held by the credential object and to destroy any
> > cryptographically sensitive information.
> >
> > Do you think it’s necessary to append something like “An implementation
> > should not rely on garbage control or a finalize() method to dispose a
> > credential”?
> >
>
> Yes.
>
>
>
> >
> > > S 6.1.15.
> > > I wouldn't say you are "creating a previously exported context". You
> > > are either importing it or creating a new context from a previously
> > > exported one.
> >
> > Accepted.
> >
> > >
> > > S 6.2.1.
> > >
> > >    // export and re-import the name
> > >    byte[] exportName = mechName.export();
> > >
> > >    // create a new name object from the exported buffer
> > >    GSSName newName = mgr.createName(exportName,
> > >                      GSSName.NT_EXPORT_NAME);
> > >
> > > This comment structure is confusing, because the first is just
> > > the export. I would change that.
> >
> > Accepted.
> >
> > >
> > >
> > > S 6.2.6.
> > > It's a bit unclear to me under what circumstances you can compare GSS
> > > names. I see you can do .equals() and export/memcmp, but can you
> > > compare strings? Perhaps after you canonicalize them?
> >
> > As Ben and I explained this is quite complicated. Can we not touch it in
> > this bis?
>
>
> The fact that it's complicated seems like more reason to explain it.

In some sense, you can always compare GSS names (in that the compare-name
function will not throw an exception), but the results may not always
match the expected behavior.  (It's too bad that RFC 6680 didn't take the
time to summarize the state of affairs when adding naming extensions.)
I don't think we should try to provide a comprehensive review of the
state of affairs in this document, nor any normative statements (that would
only apply to implementations of the Java bindings whereas the issues
apply to all GSS-API implementations).  But perhaps something like the
following would be reasonable:

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

A full treatment of the behavior of GSS name comparison is outside the
scope of this work.  However, applications should note that to avoid
surpising behavior, it is best to ensure that the names being compared
are either both mechanism names for the same mechanism, or both internal
names that are not mechanism names.  This holds whether the .equals()
method is used directly, or the .export() method is used to generate byte
strings that are then compared byte-by-byte.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Yes, this seems fine.

-Ekr


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

Benjamin Kaduk
I set a calendar reminder to ping Max when he gets back from vacation.

-Ben

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

Weijun Wang
Hi Ben

That's very kind of you. I'm still on vacation but I've flagged this mail thread and will work on it as soon as I'm back.

Thanks
Max

> On Jul 25, 2017, at 18:11, Benjamin Kaduk <[hidden email]> wrote:
>
> I set a calendar reminder to ping Max when he gets back from vacation.
>
> -Ben

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

Weijun Wang
In reply to this post by Eric Rescorla-3
Hi Ekr and Ben

Thanks a lot for you careful review and great suggestions. I'll make the following changes:

1. Append "(authentication tag)" after the first appearance of "cryptographic checksum".

2. In S 4.9, append "and might not match the initiator-requested values" after "These will reflect the actual attributes of the established context."

3. Add Ben's suggested text on GSSName comparison into S 4.13, at the end of the "GSSName objects can be compared..." paragraph.

4. And a clarification text "When neither of the methods is called, the implementation should choose a default provider for each mechanism it supports" to the introduction of addProviderAtFront() and addProviderAtEnd(), at the end of S 6.1.

I'll post a new draft soon.

Thanks
Max


> On Jul 25, 2017, at 1:04 PM, Eric Rescorla <[hidden email]> wrote:
>
>
>
> On Mon, Jul 17, 2017 at 5:22 PM, Benjamin Kaduk <[hidden email]> wrote:
> On Fri, Jul 14, 2017 at 08:57:32AM -0700, Eric Rescorla wrote:
> > On Wed, Jul 12, 2017 at 8:41 PM, Weijun Wang <[hidden email]> wrote:
> >
> > > Hi Ekr
> > >
> > > Please read my answers below to your original questions.
> > >
> > > > On Jun 18, 2017, at 2:23 AM, Eric Rescorla <[hidden email]> wrote:
> > > >
> > > > This document seems generally sound. There are some things about this
> > > > API that confused/surprised me and seem perhaps unwise, but given that
> > > > this is a bis, I will mostly confine my review to mostly calling them
> > > > out and asking you to make sure I understand and that the document is
> > > > clear.
> > > >
> > > > OVERALL
> > > > 1. What is a fatal error?
> > > > The document describes exceptions as indicating "fatal errors".
> > > > What does this mean for the state of the context. For instance,
> > > > if I receive an exception from initSecContext(), does that mean
> > > > that it is no longer possible to initiate it? Your example code
> > > > seems to treat them as fatal for the context. What happens
> > > > if I try to use a context after such an event?
> > >
> > > I’ll add a paragraph in "5.12.  Error Reporting” explaining whether the
> > > context is useable after an exception is thrown, for context establishment
> > > and per-message calls, respectively. Something like
> > >
> > > +If an exception is thrown during context establishment, the context
> > > +negotiation has failed and the GSSContext object must be abandoned.
> > > +If it is thrown in a per-message call, the context can remain useful.
> > >
> > > >
> > > >
> > > > 2. How do I enforce properties for received messages?
> > > > I see that I can request services for context initialization
> > > > (requestConf), and that I can check whether a given message
> > > > was encrypted (getPrivacy) but it's not clear to me if this
> > > > causes the API to enforce these rules for tokens that I
> > > > receive. Is that possible or do I just need to check?
> > >
> > > You would have to check. Even if an established security context already
> > > has its getConfState() being true, one can still wrap a message with
> > > privacy state set to false and the peer will unwrap it with success. If the
> > > peer insists only encrypted messages are allowed, she should always check.
> > >
> > > This is already documented in 6.4.10.
> > >
> > > >
> > > > 3. Are the request* flags() hard limits? E.g., if I do
> > > > requestMutualAuth() do I get it or fail?
> > >
> > > The method does not fail itself (i.e. does not throws an exception) and
> > > you need to check the result with those getXyzState() methods after the
> > > context is established.
> > >
> > > I can add a paragraph in S 5.9, something like:
> > >
> > > +If any retrieved attribute does not match the desired value
> > > +but it is necessary for the application protocol, the application should
> > > +destroy the security context and not use it for application traffic.
> > > +Otherwise, at this point, the context can be used by the application to
> > > +apply cryptographic services to its data.
> > >
> >
> > Sorry, I mean does the handshake fail? Or do you just hace to check.
>
> You have to check.  The GSS-API has always been a request-and-check
> type of API.
>
> OK. I think that should be explicitly stated.
>  
>
> >
> > > 4. It's a little unusual to have a structure where you keep
> > > > calling initSecContext or acceptContext() repeatedly. In
> > > > most APIs you would do like "setRole(Server)" or
> > > > "setRoleClient(), and then "Handshake().
> > >
> > > Sorry but this is how GSS-API works now.
> > >
> > > >
> > > > DETAIL
> > > > S 6.1.16.
> > > > Can addProviderAtFront() be used to add new providers which
> > > > the API would not normally use at all?
> > >
> > > No, 6.1.16 already had
> > >
> > >    Only when the indicated provider does not support
> > >    the needed mechanism should the GSSManager move on to a different
> > >    provider.
> > >
> > > I think this implies that a new provider added might be used at all.
> > >
> >
> > That doesn't seem very clear to me. My point is you might have defaults and
> > then add new omnes.
>
> I think you could use this to slot in your custom provider that was not
> part of the system Java implementation, yes.
> But I don't interact with the Java GSS stuff very much.
>
> OK. This also needs to be explicit.
>
> > > > S 5.3.
> > > > gss_release_cred() is just eager, right? In any case the data will
> > > > be cleaned up on GC? In any case you should make this clear.
> > >
> > > gss_release_cred() is eager, and there is no other guarantee the data can
> > > be automatically cleaned up. Even if GC cleaned up the GSSCredential
> > > object, there might be unreleased handles underneath.
> > >
> > > S 6.3 already has
> > >
> > >    When the credential is no longer needed, the application should call
> > > the dispose (equivalent to gss_release_cred) method to release any
> > > resources held by the credential object and to destroy any
> > > cryptographically sensitive information.
> > >
> > > Do you think it’s necessary to append something like “An implementation
> > > should not rely on garbage control or a finalize() method to dispose a
> > > credential”?
> > >
> >
> > Yes.
> >
> >
> >
> > >
> > > > S 6.1.15.
> > > > I wouldn't say you are "creating a previously exported context". You
> > > > are either importing it or creating a new context from a previously
> > > > exported one.
> > >
> > > Accepted.
> > >
> > > >
> > > > S 6.2.1.
> > > >
> > > >    // export and re-import the name
> > > >    byte[] exportName = mechName.export();
> > > >
> > > >    // create a new name object from the exported buffer
> > > >    GSSName newName = mgr.createName(exportName,
> > > >                      GSSName.NT_EXPORT_NAME);
> > > >
> > > > This comment structure is confusing, because the first is just
> > > > the export. I would change that.
> > >
> > > Accepted.
> > >
> > > >
> > > >
> > > > S 6.2.6.
> > > > It's a bit unclear to me under what circumstances you can compare GSS
> > > > names. I see you can do .equals() and export/memcmp, but can you
> > > > compare strings? Perhaps after you canonicalize them?
> > >
> > > As Ben and I explained this is quite complicated. Can we not touch it in
> > > this bis?
> >
> >
> > The fact that it's complicated seems like more reason to explain it.
>
> In some sense, you can always compare GSS names (in that the compare-name
> function will not throw an exception), but the results may not always
> match the expected behavior.  (It's too bad that RFC 6680 didn't take the
> time to summarize the state of affairs when adding naming extensions.)
> I don't think we should try to provide a comprehensive review of the
> state of affairs in this document, nor any normative statements (that would
> only apply to implementations of the Java bindings whereas the issues
> apply to all GSS-API implementations).  But perhaps something like the
> following would be reasonable:
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> A full treatment of the behavior of GSS name comparison is outside the
> scope of this work.  However, applications should note that to avoid
> surpising behavior, it is best to ensure that the names being compared
> are either both mechanism names for the same mechanism, or both internal
> names that are not mechanism names.  This holds whether the .equals()
> method is used directly, or the .export() method is used to generate byte
> strings that are then compared byte-by-byte.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>
> Yes, this seems fine.
>
> -Ekr

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

Benjamin Kaduk
Hi Max,

I hope your vacation was relaxing!

On Thu, Aug 03, 2017 at 10:45:11AM +0800, Weijun Wang wrote:

> Hi Ekr and Ben
>
> Thanks a lot for you careful review and great suggestions. I'll make the following changes:
>
> 1. Append "(authentication tag)" after the first appearance of "cryptographic checksum".
>
> 2. In S 4.9, append "and might not match the initiator-requested values" after "These will reflect the actual attributes of the established context."
>
> 3. Add Ben's suggested text on GSSName comparison into S 4.13, at the end of the "GSSName objects can be compared..." paragraph.
>
> 4. And a clarification text "When neither of the methods is called, the implementation should choose a default provider for each mechanism it supports" to the introduction of addProviderAtFront() and addProviderAtEnd(), at the end of S 6.1.

I'm not entirely sure that this addresses Ekr's concern.  Laying it out (hopefully)
more clearly, suppose that I have a java standard library that provides GSSAPI
support, and supports the krb5 and ntlm mechanisms.  It's clear that my
application code could supply an alternate provider for the krb5 mech and
have that used preferentially.  But could my application code also supply
a provider for, say, the IAKERB mech via addProviderAtFront, and have that used?

Regardless, thanks for these edits -- I look forward to the new revision.

-Ben


 

> I'll post a new draft soon.
>
> Thanks
> Max
>
>
> > On Jul 25, 2017, at 1:04 PM, Eric Rescorla <[hidden email]> wrote:
> >
> >
> >
> > On Mon, Jul 17, 2017 at 5:22 PM, Benjamin Kaduk <[hidden email]> wrote:
> > On Fri, Jul 14, 2017 at 08:57:32AM -0700, Eric Rescorla wrote:
> > > On Wed, Jul 12, 2017 at 8:41 PM, Weijun Wang <[hidden email]> wrote:
> > >
> > > > Hi Ekr
> > > >
> > > > Please read my answers below to your original questions.
> > > >
> > > > > On Jun 18, 2017, at 2:23 AM, Eric Rescorla <[hidden email]> wrote:
> > > > >
> > > > > This document seems generally sound. There are some things about this
> > > > > API that confused/surprised me and seem perhaps unwise, but given that
> > > > > this is a bis, I will mostly confine my review to mostly calling them
> > > > > out and asking you to make sure I understand and that the document is
> > > > > clear.
> > > > >
> > > > > OVERALL
> > > > > 1. What is a fatal error?
> > > > > The document describes exceptions as indicating "fatal errors".
> > > > > What does this mean for the state of the context. For instance,
> > > > > if I receive an exception from initSecContext(), does that mean
> > > > > that it is no longer possible to initiate it? Your example code
> > > > > seems to treat them as fatal for the context. What happens
> > > > > if I try to use a context after such an event?
> > > >
> > > > I’ll add a paragraph in "5.12.  Error Reporting” explaining whether the
> > > > context is useable after an exception is thrown, for context establishment
> > > > and per-message calls, respectively. Something like
> > > >
> > > > +If an exception is thrown during context establishment, the context
> > > > +negotiation has failed and the GSSContext object must be abandoned.
> > > > +If it is thrown in a per-message call, the context can remain useful.
> > > >
> > > > >
> > > > >
> > > > > 2. How do I enforce properties for received messages?
> > > > > I see that I can request services for context initialization
> > > > > (requestConf), and that I can check whether a given message
> > > > > was encrypted (getPrivacy) but it's not clear to me if this
> > > > > causes the API to enforce these rules for tokens that I
> > > > > receive. Is that possible or do I just need to check?
> > > >
> > > > You would have to check. Even if an established security context already
> > > > has its getConfState() being true, one can still wrap a message with
> > > > privacy state set to false and the peer will unwrap it with success. If the
> > > > peer insists only encrypted messages are allowed, she should always check.
> > > >
> > > > This is already documented in 6.4.10.
> > > >
> > > > >
> > > > > 3. Are the request* flags() hard limits? E.g., if I do
> > > > > requestMutualAuth() do I get it or fail?
> > > >
> > > > The method does not fail itself (i.e. does not throws an exception) and
> > > > you need to check the result with those getXyzState() methods after the
> > > > context is established.
> > > >
> > > > I can add a paragraph in S 5.9, something like:
> > > >
> > > > +If any retrieved attribute does not match the desired value
> > > > +but it is necessary for the application protocol, the application should
> > > > +destroy the security context and not use it for application traffic.
> > > > +Otherwise, at this point, the context can be used by the application to
> > > > +apply cryptographic services to its data.
> > > >
> > >
> > > Sorry, I mean does the handshake fail? Or do you just hace to check.
> >
> > You have to check.  The GSS-API has always been a request-and-check
> > type of API.
> >
> > OK. I think that should be explicitly stated.
> >  
> >
> > >
> > > > 4. It's a little unusual to have a structure where you keep
> > > > > calling initSecContext or acceptContext() repeatedly. In
> > > > > most APIs you would do like "setRole(Server)" or
> > > > > "setRoleClient(), and then "Handshake().
> > > >
> > > > Sorry but this is how GSS-API works now.
> > > >
> > > > >
> > > > > DETAIL
> > > > > S 6.1.16.
> > > > > Can addProviderAtFront() be used to add new providers which
> > > > > the API would not normally use at all?
> > > >
> > > > No, 6.1.16 already had
> > > >
> > > >    Only when the indicated provider does not support
> > > >    the needed mechanism should the GSSManager move on to a different
> > > >    provider.
> > > >
> > > > I think this implies that a new provider added might be used at all.
> > > >
> > >
> > > That doesn't seem very clear to me. My point is you might have defaults and
> > > then add new omnes.
> >
> > I think you could use this to slot in your custom provider that was not
> > part of the system Java implementation, yes.
> > But I don't interact with the Java GSS stuff very much.
> >
> > OK. This also needs to be explicit.
> >
> > > > > S 5.3.
> > > > > gss_release_cred() is just eager, right? In any case the data will
> > > > > be cleaned up on GC? In any case you should make this clear.
> > > >
> > > > gss_release_cred() is eager, and there is no other guarantee the data can
> > > > be automatically cleaned up. Even if GC cleaned up the GSSCredential
> > > > object, there might be unreleased handles underneath.
> > > >
> > > > S 6.3 already has
> > > >
> > > >    When the credential is no longer needed, the application should call
> > > > the dispose (equivalent to gss_release_cred) method to release any
> > > > resources held by the credential object and to destroy any
> > > > cryptographically sensitive information.
> > > >
> > > > Do you think it’s necessary to append something like “An implementation
> > > > should not rely on garbage control or a finalize() method to dispose a
> > > > credential”?
> > > >
> > >
> > > Yes.
> > >
> > >
> > >
> > > >
> > > > > S 6.1.15.
> > > > > I wouldn't say you are "creating a previously exported context". You
> > > > > are either importing it or creating a new context from a previously
> > > > > exported one.
> > > >
> > > > Accepted.
> > > >
> > > > >
> > > > > S 6.2.1.
> > > > >
> > > > >    // export and re-import the name
> > > > >    byte[] exportName = mechName.export();
> > > > >
> > > > >    // create a new name object from the exported buffer
> > > > >    GSSName newName = mgr.createName(exportName,
> > > > >                      GSSName.NT_EXPORT_NAME);
> > > > >
> > > > > This comment structure is confusing, because the first is just
> > > > > the export. I would change that.
> > > >
> > > > Accepted.
> > > >
> > > > >
> > > > >
> > > > > S 6.2.6.
> > > > > It's a bit unclear to me under what circumstances you can compare GSS
> > > > > names. I see you can do .equals() and export/memcmp, but can you
> > > > > compare strings? Perhaps after you canonicalize them?
> > > >
> > > > As Ben and I explained this is quite complicated. Can we not touch it in
> > > > this bis?
> > >
> > >
> > > The fact that it's complicated seems like more reason to explain it.
> >
> > In some sense, you can always compare GSS names (in that the compare-name
> > function will not throw an exception), but the results may not always
> > match the expected behavior.  (It's too bad that RFC 6680 didn't take the
> > time to summarize the state of affairs when adding naming extensions.)
> > I don't think we should try to provide a comprehensive review of the
> > state of affairs in this document, nor any normative statements (that would
> > only apply to implementations of the Java bindings whereas the issues
> > apply to all GSS-API implementations).  But perhaps something like the
> > following would be reasonable:
> >
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> >
> > A full treatment of the behavior of GSS name comparison is outside the
> > scope of this work.  However, applications should note that to avoid
> > surpising behavior, it is best to ensure that the names being compared
> > are either both mechanism names for the same mechanism, or both internal
> > names that are not mechanism names.  This holds whether the .equals()
> > method is used directly, or the .export() method is used to generate byte
> > strings that are then compared byte-by-byte.
> >
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> >
> > Yes, this seems fine.
> >
> > -Ekr
>

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

Weijun Wang

> On Aug 4, 2017, at 8:40 AM, Benjamin Kaduk <[hidden email]> wrote:
>
> Hi Max,
>
> I hope your vacation was relaxing!

Mentally yes, physically not really.

>
> On Thu, Aug 03, 2017 at 10:45:11AM +0800, Weijun Wang wrote:
>> Hi Ekr and Ben
>>
>> Thanks a lot for you careful review and great suggestions. I'll make the following changes:
>>
>> 1. Append "(authentication tag)" after the first appearance of "cryptographic checksum".
>>
>> 2. In S 4.9, append "and might not match the initiator-requested values" after "These will reflect the actual attributes of the established context."
>>
>> 3. Add Ben's suggested text on GSSName comparison into S 4.13, at the end of the "GSSName objects can be compared..." paragraph.
>>
>> 4. And a clarification text "When neither of the methods is called, the implementation should choose a default provider for each mechanism it supports" to the introduction of addProviderAtFront() and addProviderAtEnd(), at the end of S 6.1.
>
> I'm not entirely sure that this addresses Ekr's concern.  Laying it out (hopefully)
> more clearly, suppose that I have a java standard library that provides GSSAPI
> support, and supports the krb5 and ntlm mechanisms.  It's clear that my
> application code could supply an alternate provider for the krb5 mech and
> have that used preferentially.  But could my application code also supply
> a provider for, say, the IAKERB mech via addProviderAtFront, and have that used?

Yes, you can.

That said, it's not easy. The Java bindings of GSS-API do not contain public available interfaces for mechanism providers, and each GSS-API implementation defines its own interfaces. So if you want to write a IAKERB provider for Oracle's Java (or OpenJDK), you need to extend Oracle's interfaces. If you want to write one for IBM's Java, you extend IBM's interfaces. At least for Oracle JDK, these interfaces are internal so you end up releasing your own fork of JDK.

>
> Regardless, thanks for these edits -- I look forward to the new revision.

Working on it.

Thanks
Max

>
> -Ben
>
>
>
>> I'll post a new draft soon.
>>
>> Thanks
>> Max
>>
>>
>>> On Jul 25, 2017, at 1:04 PM, Eric Rescorla <[hidden email]> wrote:
>>>
>>>
>>>
>>> On Mon, Jul 17, 2017 at 5:22 PM, Benjamin Kaduk <[hidden email]> wrote:
>>> On Fri, Jul 14, 2017 at 08:57:32AM -0700, Eric Rescorla wrote:
>>>> On Wed, Jul 12, 2017 at 8:41 PM, Weijun Wang <[hidden email]> wrote:
>>>>
>>>>> Hi Ekr
>>>>>
>>>>> Please read my answers below to your original questions.
>>>>>
>>>>>> On Jun 18, 2017, at 2:23 AM, Eric Rescorla <[hidden email]> wrote:
>>>>>>
>>>>>> This document seems generally sound. There are some things about this
>>>>>> API that confused/surprised me and seem perhaps unwise, but given that
>>>>>> this is a bis, I will mostly confine my review to mostly calling them
>>>>>> out and asking you to make sure I understand and that the document is
>>>>>> clear.
>>>>>>
>>>>>> OVERALL
>>>>>> 1. What is a fatal error?
>>>>>> The document describes exceptions as indicating "fatal errors".
>>>>>> What does this mean for the state of the context. For instance,
>>>>>> if I receive an exception from initSecContext(), does that mean
>>>>>> that it is no longer possible to initiate it? Your example code
>>>>>> seems to treat them as fatal for the context. What happens
>>>>>> if I try to use a context after such an event?
>>>>>
>>>>> I’ll add a paragraph in "5.12.  Error Reporting” explaining whether the
>>>>> context is useable after an exception is thrown, for context establishment
>>>>> and per-message calls, respectively. Something like
>>>>>
>>>>> +If an exception is thrown during context establishment, the context
>>>>> +negotiation has failed and the GSSContext object must be abandoned.
>>>>> +If it is thrown in a per-message call, the context can remain useful.
>>>>>
>>>>>>
>>>>>>
>>>>>> 2. How do I enforce properties for received messages?
>>>>>> I see that I can request services for context initialization
>>>>>> (requestConf), and that I can check whether a given message
>>>>>> was encrypted (getPrivacy) but it's not clear to me if this
>>>>>> causes the API to enforce these rules for tokens that I
>>>>>> receive. Is that possible or do I just need to check?
>>>>>
>>>>> You would have to check. Even if an established security context already
>>>>> has its getConfState() being true, one can still wrap a message with
>>>>> privacy state set to false and the peer will unwrap it with success. If the
>>>>> peer insists only encrypted messages are allowed, she should always check.
>>>>>
>>>>> This is already documented in 6.4.10.
>>>>>
>>>>>>
>>>>>> 3. Are the request* flags() hard limits? E.g., if I do
>>>>>> requestMutualAuth() do I get it or fail?
>>>>>
>>>>> The method does not fail itself (i.e. does not throws an exception) and
>>>>> you need to check the result with those getXyzState() methods after the
>>>>> context is established.
>>>>>
>>>>> I can add a paragraph in S 5.9, something like:
>>>>>
>>>>> +If any retrieved attribute does not match the desired value
>>>>> +but it is necessary for the application protocol, the application should
>>>>> +destroy the security context and not use it for application traffic.
>>>>> +Otherwise, at this point, the context can be used by the application to
>>>>> +apply cryptographic services to its data.
>>>>>
>>>>
>>>> Sorry, I mean does the handshake fail? Or do you just hace to check.
>>>
>>> You have to check.  The GSS-API has always been a request-and-check
>>> type of API.
>>>
>>> OK. I think that should be explicitly stated.
>>>
>>>
>>>>
>>>>> 4. It's a little unusual to have a structure where you keep
>>>>>> calling initSecContext or acceptContext() repeatedly. In
>>>>>> most APIs you would do like "setRole(Server)" or
>>>>>> "setRoleClient(), and then "Handshake().
>>>>>
>>>>> Sorry but this is how GSS-API works now.
>>>>>
>>>>>>
>>>>>> DETAIL
>>>>>> S 6.1.16.
>>>>>> Can addProviderAtFront() be used to add new providers which
>>>>>> the API would not normally use at all?
>>>>>
>>>>> No, 6.1.16 already had
>>>>>
>>>>>   Only when the indicated provider does not support
>>>>>   the needed mechanism should the GSSManager move on to a different
>>>>>   provider.
>>>>>
>>>>> I think this implies that a new provider added might be used at all.
>>>>>
>>>>
>>>> That doesn't seem very clear to me. My point is you might have defaults and
>>>> then add new omnes.
>>>
>>> I think you could use this to slot in your custom provider that was not
>>> part of the system Java implementation, yes.
>>> But I don't interact with the Java GSS stuff very much.
>>>
>>> OK. This also needs to be explicit.
>>>
>>>>>> S 5.3.
>>>>>> gss_release_cred() is just eager, right? In any case the data will
>>>>>> be cleaned up on GC? In any case you should make this clear.
>>>>>
>>>>> gss_release_cred() is eager, and there is no other guarantee the data can
>>>>> be automatically cleaned up. Even if GC cleaned up the GSSCredential
>>>>> object, there might be unreleased handles underneath.
>>>>>
>>>>> S 6.3 already has
>>>>>
>>>>>   When the credential is no longer needed, the application should call
>>>>> the dispose (equivalent to gss_release_cred) method to release any
>>>>> resources held by the credential object and to destroy any
>>>>> cryptographically sensitive information.
>>>>>
>>>>> Do you think it’s necessary to append something like “An implementation
>>>>> should not rely on garbage control or a finalize() method to dispose a
>>>>> credential”?
>>>>>
>>>>
>>>> Yes.
>>>>
>>>>
>>>>
>>>>>
>>>>>> S 6.1.15.
>>>>>> I wouldn't say you are "creating a previously exported context". You
>>>>>> are either importing it or creating a new context from a previously
>>>>>> exported one.
>>>>>
>>>>> Accepted.
>>>>>
>>>>>>
>>>>>> S 6.2.1.
>>>>>>
>>>>>>   // export and re-import the name
>>>>>>   byte[] exportName = mechName.export();
>>>>>>
>>>>>>   // create a new name object from the exported buffer
>>>>>>   GSSName newName = mgr.createName(exportName,
>>>>>>                     GSSName.NT_EXPORT_NAME);
>>>>>>
>>>>>> This comment structure is confusing, because the first is just
>>>>>> the export. I would change that.
>>>>>
>>>>> Accepted.
>>>>>
>>>>>>
>>>>>>
>>>>>> S 6.2.6.
>>>>>> It's a bit unclear to me under what circumstances you can compare GSS
>>>>>> names. I see you can do .equals() and export/memcmp, but can you
>>>>>> compare strings? Perhaps after you canonicalize them?
>>>>>
>>>>> As Ben and I explained this is quite complicated. Can we not touch it in
>>>>> this bis?
>>>>
>>>>
>>>> The fact that it's complicated seems like more reason to explain it.
>>>
>>> In some sense, you can always compare GSS names (in that the compare-name
>>> function will not throw an exception), but the results may not always
>>> match the expected behavior.  (It's too bad that RFC 6680 didn't take the
>>> time to summarize the state of affairs when adding naming extensions.)
>>> I don't think we should try to provide a comprehensive review of the
>>> state of affairs in this document, nor any normative statements (that would
>>> only apply to implementations of the Java bindings whereas the issues
>>> apply to all GSS-API implementations).  But perhaps something like the
>>> following would be reasonable:
>>>
>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>>
>>> A full treatment of the behavior of GSS name comparison is outside the
>>> scope of this work.  However, applications should note that to avoid
>>> surpising behavior, it is best to ensure that the names being compared
>>> are either both mechanism names for the same mechanism, or both internal
>>> names that are not mechanism names.  This holds whether the .equals()
>>> method is used directly, or the .export() method is used to generate byte
>>> strings that are then compared byte-by-byte.
>>>
>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>>
>>> Yes, this seems fine.
>>>
>>> -Ekr

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

Weijun Wang
In reply to this post by Benjamin Kaduk

> On Aug 4, 2017, at 8:40 AM, Benjamin Kaduk <[hidden email]> wrote:
>
>> 4. And a clarification text "When neither of the methods is called, the implementation should choose a default provider for each mechanism it supports" to the introduction of addProviderAtFront() and addProviderAtEnd(), at the end of S 6.1.
>
> I'm not entirely sure that this addresses Ekr's concern.  Laying it out (hopefully)
> more clearly, suppose that I have a java standard library that provides GSSAPI
> support, and supports the krb5 and ntlm mechanisms.  It's clear that my
> application code could supply an alternate provider for the krb5 mech and
> have that used preferentially.  But could my application code also supply
> a provider for, say, the IAKERB mech via addProviderAtFront, and have that used?

I think this is already covered in https://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-04#page-34:

> 3) The application wants to use the locally configured providers as
>       far as possible, but if support is missing for one or more
>       mechanisms, then it wants to fall back on its own provider.

Here, support for the IAKERB mech "is missing", and user provides "its own provider". Of course in this case, calling addProviderAtFront or addProviderAtEnd makes no difference.

Thanks
Max

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

Re: [kitten] AD Review: draft-ietf-kitten-rfc5653bis-04

Weijun Wang
In reply to this post by Benjamin Kaduk

> On Aug 4, 2017, at 8:40 AM, Benjamin Kaduk <[hidden email]> wrote:
>
> Regardless, thanks for these edits -- I look forward to the new revision.

Just posted https://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-05.

Thanks
Max

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten