Re: prot_ready, CFX and Larry's enctype negotiation draft

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <lzhu <at> windows.microsoft.com> writes:

    Liqiang(Larry)> IIUC, Nico and I have difference in opinion only
    Liqiang(Larry)> for the question whether we can say the acceptor
    Liqiang(Larry)> that implements RFC4121 MUST support prot_ready.
    Liqiang(Larry)> Nico, if I did not summarize our discussion here
    Liqiang(Larry)> correctly, please let me know.

I think you also have a conflict among the authors of RFc 4121.  It is
clear to me that the WG intended to require acceptors to support
prot_ready and I believe the text does that.

The question is whether we want to require initiators not to offer or
use prot_ready if enctype negotiation is used.

I think that's a reasonable compromise and support it.

Re: prot_ready, CFX and Larry's enctype negotiation draft

On Wed, Oct 05, 2005 at 05:28:46PM -0400, Sam Hartman wrote:
> >>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <lzhu <at> windows.microsoft.com> writes:
> 
> 
>     Liqiang(Larry)> IIUC, Nico and I have difference in opinion only
>     Liqiang(Larry)> for the question whether we can say the acceptor
>     Liqiang(Larry)> that implements RFC4121 MUST support prot_ready.
>     Liqiang(Larry)> Nico, if I did not summarize our discussion here
>     Liqiang(Larry)> correctly, please let me know.
> 
> I think you also have a conflict among the authors of RFc 4121.  It is
> clear to me that the WG intended to require acceptors to support
> prot_ready and I believe the text does that.
> 
> The question is whether we want to require initiators not to offer or
> use prot_ready if enctype negotiation is used.
> 
> I think that's a reasonable compromise and support it.

At first glance it does indeed seem reasonable, if unfortunate.

I have to think about it.

rcf4120 vs. rfc4121

Re: rcf4120 vs. rfc4121

Michael Chapel wrote:

> Which I assumed if a subkey was asserted that it would be encrypted with
> the subkey. Yet in rfc4121 it states:
> 
> 
>    The checksum type MUST be 0x8003.  When delegation is used, a
>    ticket-granting ticket will be transferred in a KRB_CRED message.
>    This ticket SHOULD have its forwardable flag set.  The EncryptedData
>    field of the KRB_CRED message [RFC4120] MUST be encrypted in the
>    session key of the ticket used to authenticate the context.
> 
> Doesn't these two contradict each other. And if not, could you explain
> to me why this is so.

The text from 4121 is describing the requirements of the KRB_AP
exchange.  Therefore, you have not yet negotiated a subkey via KRB_AP.

Jeffrey Altman

Re: rcf4120 vs. rfc4121

Michael Chapel wrote:
> 
> I'm a bit confused by the wording between the two rfc's about the KRB_CRED 
> encyption key. They don't seem to be in sync with each others statements:

It appears that you're rightfully confused.

> 
> In rfc4120 it states:
> 
>  The current
>    time and, if they are specifically required by the application, the
>    nonce, s-address, and r-address fields are placed in the encrypted
>    part of the KRB_CRED message, which is then encrypted under an
>    encryption key previously exchanged in the KRB_AP exchange (usually
>    the last key negotiated via subkeys, or the session key if no
>    negotiation has occurred).
> 
> Which I assumed if a subkey was asserted that it would be encrypted with 
> the subkey.

This is exactly what was written in rfc1510 Section 3.6.1 generating
the KRB_CRED message.

RFC-1964 (predecessor of rfc4121) is unfortunately silent about the details
of the generation of the KRB_CRED message.

>    Yet in rfc4121 it states:
> 
> 
>    The checksum type MUST be 0x8003.  When delegation is used, a
>    ticket-granting ticket will be transferred in a KRB_CRED message.
>    This ticket SHOULD have its forwardable flag set.  The EncryptedData
>    field of the KRB_CRED message [RFC4120] MUST be encrypted in the
>    session key of the ticket used to authenticate the context.
> 
> Doesn't these two contradict each other. And if not, could you explain to 
> me why this is so. 

They don't fully contradict, the use of negotiated subkeys is described
as some sort of "tradition", which I read as a "MAY".

From previous discussions about subkey negotiation, it appears to me that
implementations often lacked (real) subkey negotiation, so it was not really
a tradition after all, in spite of what rfc1510 and rfc4121 suggests.

Keep in mind that the KRB_CRED message in rfc-1964 Kerberos and CFX
is included in the AP_REQ message, so it could NEVER be protected under
a subkey asserted by an acceptor in AP_REP in the way rfc1510 and rfc4120
suggest in the parentheses "last subkey".

Looking at MIT Kerberos 1.0.5, it appears that the KRB_CRED message
is created before AP_REQ is created (during gss_init_sec_context),
so there KRB_CRED will be protected under the ticket session key
and not the initiator-asserted subkey from the accompanying AP_REQ.

-Martin

Re: rcf4120 vs. rfc4121

Fwd: [saag] Fwd: New Public Review Issue: UTR #36, UTS #39 (Security)

In case anyone's not on SAAG...
Ken

Begin forwarded message:
> From: Paul Hoffman <paul.hoffman <at> vpnc.org>
> Date: October 11, 2005 18:20:48 EDT
> To: saag <at> mit.edu
> Subject: [saag] Fwd: New Public Review Issue: UTR #36, UTS #39  
> (Security)
> X-Spam-Score: -2.599
>
>
> Of interest to many in this group:
>
>
>> To: unicode <at> unicode.org
>> Subject: New Public Review Issue: UTR #36, UTS #39 (Security)
>> Date: Tue, 11 Oct 2005 13:27:33 -0700
>> From: Rick McGowan <rick <at> unicode.org>
>> X-archive-position: 231
>> X-ecartis-version: Ecartis v1.0.0
>> Sender: unicore-bounce <at> unicode.org
>> X-original-sender: rick <at> unicode.org
>>
>> The Unicode Technical Committee has posted a new issue for public  
>> review and comment. Details are on the following web page:
>>
>>     http://www.unicode.org/review/
>>
>> Review period for the new item closes on October 24, 2005.
>>
>> Please see the page for links to discussion and relevant documents.
>> Briefly, the new issue is:
>>
>>
>> 77  Proposed Draft UTS #39 and Proposed Update UTR #36 (close  
>> 2005-10-24)
>>
>> The sections of UTR #36: Unicode Security Considerations that  
>> pertain to security functions have been split off into a new  
>> proposed draft UTS #39: Unicode Security Mechanisms. In addition,  
>> a section on some of the problems with language-based security has  
>> been added to UTR #36. We would appreciate feedback on the  
>> proposed changes, and comments on the security issues highlighted  
>> in UTR #36. See:
>>
>>     http://www.unicode.org/reports/tr36/tr36-4.html
>>     http://www.unicode.org/reports/tr39/tr39-1.html
>>
>>
>> If you have comments for official UTC consideration, please post  
>> them by submitting your comments through our feedback & reporting  
>> page:
>>
>>     http://www.unicode.org/reporting.html
>>
>> If you wish to discuss issues on the Unicode mail list, then  
>> please use the following link to subscribe (if necessary). Please  
>> be aware that discussion comments on the Unicode mail list are not  
>> automatically recorded as input to the UTC. You must use the  
>> reporting link above to generate comments for UTC consideration.
>>
>>     http://www.unicode.org/consortium/distlist.html
>>
>> Regards,
>>     Rick McGowan
>>     Unicode, Inc.
>>
>
> _______________________________________________
> saag mailing list
> saag <at> mit.edu
> https://jis.mit.edu/mailman/listinfo/saag
>

RE: rcf4120 vs. rfc4121

Re: rcf4120 vs. rfc4121

Michael Chapel <mchapel <at> us.ibm.com> writes:

> I'm a bit confused by the wording between the two rfc's about the KRB_CRED
> encyption key. They don't seem to be in sync with each others statements:
[...]
> Doesn't these two contradict each other. And if not, could you explain to me
> why this is so.

There are some implementations that both uses subkey and some uses session
key existing today, so its a good idea to check both. To makes things
"better", there is also the "NULL" encrypted KRB_CRED used for GSS-API for
older enctypes.

Love

RE: rcf4120 vs. rfc4121