Sam Hartman | 1 Dec 14:44 2003
Picon

Re: Checksum flags field (section 4.1.1.1) in gssapi-cfx-04


The anonymous flag is not currently supported by this mechanism.
There's currently no way to do that with Kerberos, so it is not
reasonable for an implementation of this mechanism to send that flag.

The prot_ready flag need not be sent over the wire to be useful.

Wyllys Ingersoll | 1 Dec 15:54 2003
Picon

gssapi-cfx-04.txt section 5.1.1 question

This is a nit,but section 5.1.1 is titled "Non-Kerberos Specific Codes"
but all of the codes defined are named "GSS_KRB5_S_G_***".
If they are "non-kerberos-specific", should the "_KRB5_" bit of those
names be dropped?

-Wyllys Ingersoll

Liqiang(Larry) Zhu | 1 Dec 19:45 2003
Picon

RE: Checksum flags field (section 4.1.1.1) in gssapi-cfx-04

Is it meaningful to set GSS_C_TRANS_FLAG? Would the acceptor behave
differently if this bit is set?

Simon Josefsson wrote:
>> Are these allowed to be set by implementations that support them?
>> Are receivers forced to ignore them if they are set?

Yes, this document does not prohibit setting additional flags.

The receivers are not forced to ignore the flags that are not listed in
this document, for example, they might know other flags that are defined
in a future document.

Larry

-----Original Message-----
From: owner-ietf-krb-wg <at> achilles.ctd.anl.gov
[mailto:owner-ietf-krb-wg <at> achilles.ctd.anl.gov] On Behalf Of Simon
Josefsson
Sent: Thursday, November 27, 2003 6:16 AM
To: Douglas E. Engert
Cc: Kerberos WG; Russell Housley; Steven M. Bellovin
Subject: Checksum flags field (section 4.1.1.1) in gssapi-cfx-04

RFC 2744 define the following flags as well:

   #define GSS_C_ANON_FLAG       64
   #define GSS_C_PROT_READY_FLAG 128
   #define GSS_C_TRANS_FLAG      256

(Continue reading)

Liqiang(Larry) Zhu | 1 Dec 19:34 2003
Picon

RE: Checksum flags field (section 4.1.1.1) in gssapi-cfx-04

Simon Josefsson wrote:

> One editorial issues: The document reserve certain bit sequences in
> several places (4.1.1.1, 4.2.2, and 4.4).  Because some of these texts
> appear to be directed to IANA or IETF (e.g., section 4.4 "Token
> identifiers ... are reserved and SHALL NOT be assigned."), and not to
> protocol implementors, I think they should placed in a separate
> section.

Curtsey of jhutz+ <at> cmu.edu: The TOK_ID values aren't used outside this
mechanism, and they're not intended as a way for other people to extend
the protocol.  Since new ones should only be allocated as part of
specifying a future version of the mechanism (which will presumably
obsolete this version, or at least update it), I don't think an IANA
registry is necessary.  This WG is already creating lots of work for
IANA; let's not invent more where it doesn't need to exist.

Similarly, I do not think we need work for IANA for the checksum flags.

Thanks,

Larry
-----Original Message-----
From: owner-ietf-krb-wg <at> achilles.ctd.anl.gov
[mailto:owner-ietf-krb-wg <at> achilles.ctd.anl.gov] On Behalf Of Simon
Josefsson
Sent: Thursday, November 27, 2003 6:16 AM
To: Douglas E. Engert
Cc: Kerberos WG; Russell Housley; Steven M. Bellovin
Subject: Checksum flags field (section 4.1.1.1) in gssapi-cfx-04
(Continue reading)

Martin Rex | 1 Dec 20:55 2003
Picon

Re: Checksum flags field (section 4.1.1.1) in gssapi-cfx-04

Simon Josefsson wrote:
> 
> RFC 2744 define the following flags as well:
> 
>    #define GSS_C_ANON_FLAG       64
>    #define GSS_C_PROT_READY_FLAG 128
>    #define GSS_C_TRANS_FLAG      256
> 
> Are these allowed to be set by implementations that support them?
> Are receivers forced to ignore them if they are set?

GSS_C_TRANS_FLAG and GSS_PROT_READY_FLAG are only relevant for the
local implementation, both peers have to *locally* and *independently*
decide whether they support this feature at the API level or not.

GSS_C_TRANS_FLAG is an indicator that the optional
gss_export_sec_context()/gss_import_sec_context() facility is
available for use with a security context (usually to transfer
the security context to another process).

GSS_C_PROT_READY may be used to indicate that message protection
services are available for use before a security context is
fully established (i.e. before the context establishment call
gss_init_sec_context or gss_accept_sec_context has returned
GSS_S_COMPLETE (and so far it is the only flag that an application
can evaluate *before* the context establishment call returns
GSS_S_COMPLETE).

-Martin

(Continue reading)

Douglas E. Engert | 1 Dec 21:23 2003

Failure of some sites to receive ietf-krb-wg mail

I am again receiving bounced mail form some sites where the hopcount is set to low. 

If you name is in the cc list, you may be missing messages from the ietf-krb-wg
list (as well as other mail lists.) Please contact you mail server administrator 
to request that the max hopcount be increased to 25.   

These bounced mail messages are generated at Microsoft, where their mail systems 
take 7 hops to deliver the mail to the majordomo at anl.gov, which adds
7 or so hops before sending it on. a few extra hops are added by the receiving
systems pushing the hopcount in a message to more then 17 which appears to be 
an old default.  

In these days of spam filters at the sender, receiver and mail list sites 
the default of 17 is just to low a value of 25 is more realistic.    

--

-- 

 Douglas E. Engert  <DEEngert <at> anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

Sam Hartman | 2 Dec 16:11 2003
Picon

Last call comments on draft-ietf-krb-wg-gssapi-cfx


Hi.  I have read draft-ietf-gssapi-cfx and believe this draft should
be published as a proposed standard.

I would like to suggest the following clarifications to the text.

Consider adding the following just before the beginning of section 4.2:

If the caller to gss_accept_sec_context passes in GSS_C_NO_BINDINGS as
the channel bindings then the acceptor {MAY|SHOULD|MUST} ignore any
channel bindings supplied by the initiator, returning success even if the initiator did pass in channel bindings.

I believe this reflects current practice in several Kerberos
implementations as we migrate away from the use of IP-based channel
bindings.

My preference is for SHOULD or MUST, not for MAY in the above
sentence.

Section 4.2.6.1 still has the old token format, implying that the
to_be_signed data comes after the header in the checksum.

I think section 7 (security considerations) is probably the weakest
section of the document.  AT this time, I don't have additional things
to suggest adding to that section.  I believe the security
considerations against this GSSAPI mechanism are no different than
those for Kerberos and kcrypto.

Sam Hartman | 2 Dec 17:51 2003
Picon

Re: gssapi-cfx-04.txt section 5.1.1 question

>>>>> "Wyllys" == Wyllys Ingersoll <wyllys.ingersoll <at> sun.com> writes:

    Wyllys> This is a nit,but section 5.1.1 is titled "Non-Kerberos Specific Codes"
    Wyllys> but all of the codes defined are named "GSS_KRB5_S_G_***".
    Wyllys> If they are "non-kerberos-specific", should the "_KRB5_" bit of those
    Wyllys> names be dropped?

No.  These error codes are specific to the krb5 GSSAPI mechanism even
though they represent more general problems than a kerberos problem.

Douglas E. Engert | 2 Dec 22:52 2003

gssapi-cfx-04.txt section 4.1.1 question


The Dlgth field in the checksum is only two bytes long. This may be to small
should it be 4 bytes? 

A recent change in Microsoft was to increase the maximum allowed ticket 
size from 8K to 12K indicting that there are now tickets larger then 8K. 

With all the extensions to tickets, I expect we may see tickets large then 
64K in the future which could not be delegated.

--

-- 

 Douglas E. Engert  <DEEngert <at> anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

Ken Raeburn | 2 Dec 23:07 2003
Picon

gssapi-cfx-04: references

Since [AES-KRB5] is only referenced in a "for example", I think it
could probably be an informative rather than normative reference.

Ken


Gmane