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.
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
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)
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)
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)
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
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.
>>>>> "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.
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
RSS Feed2 | |
|---|---|
1 | |
2 | |
1 | |
9 | |
13 | |
23 | |
21 | |
17 | |
94 | |
8 | |
28 | |
70 | |
149 | |
17 | |
23 | |
69 | |
56 | |
38 | |
84 | |
183 | |
93 | |
165 | |
49 | |
55 | |
32 | |
56 | |
49 | |
43 | |
170 | |
46 | |
83 | |
35 | |
12 | |
99 | |
13 | |
52 | |
16 | |
5 | |
21 | |
36 | |
122 | |
81 | |
44 | |
97 | |
102 | |
56 | |
64 | |
223 | |
24 | |
45 | |
60 | |
63 | |
18 | |
54 | |
140 | |
87 | |
4 | |
2 | |
21 | |
17 | |
32 | |
50 | |
62 | |
54 | |
41 | |
6 | |
52 | |
57 | |
37 | |
42 | |
35 | |
66 | |
13 | |
10 | |
6 | |
19 | |
24 | |
73 | |
46 | |
29 | |
47 | |
26 | |
36 | |
40 | |
42 | |
78 | |
28 | |
109 | |
90 | |
138 | |
84 | |
162 | |
59 | |
58 | |
42 | |
60 | |
175 | |
78 | |
42 | |
57 | |
114 | |
217 | |
52 | |
229 | |
70 | |
76 | |
111 | |
105 | |
95 | |
27 | |
114 | |
69 | |
254 | |
192 | |
113 | |
118 | |
62 | |
59 | |
91 | |
80 | |
47 | |
33 | |
187 | |
170 | |
101 | |
25 | |
21 | |
15 | |
29 | |
13 | |
49 |
