[SPKM] Re: Comments on draft-zhu-pku2u-01.txt

Liqiang wrote:
> 
> Nicolas.Williams wrote:
> > Where does GSS_S_CONTINUE_NEEDED appear in the KRB-ERROR??  Normally
> > status codes like GSS_S_CONTINUE_NEEDED are not sent in a mechanism
> > token -- they are implied.
> 
> See section 6 of the user2user ID
> http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.txt
> 
>     
> 6. User to User when applied by server policy 
>     
>    In the case that the client application doesn't know that a service 
>    requires user-to-user authentication, and requests and receives a 
>    conventional KRB_AP_REP, the client will send the KRB_AP_REP 

Is it me or should this read KRB_AP_REQ? 

>    request, and the server will respond with a KRB_ERROR token as 
>    described in RFC1964, with a msg-type of 
>    KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may optionally 
>    pass the TGT in the data field of this error message. In response to 
>    this error, the initiator sets flags and returns a 
>    GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism 
>    described in section 4.

This "server policy" confuses me.

There are potentially 3 issues with AP_REQ/AP_REP exchanges that
I can think of:

  1) "weak" server key (i.e. server does not have a strong random key)

  2) server lacks (or doesn't want to use) replay cache

  3) replay caches are not shared across hosts, so a distributed services
     using a single principal (a single key) instead of the original
     hostbased services of the original Kerberos 5 design become
     vulnerable to cross-host replay

Protection for (1) would require the KDC to not even issue
service tickets, so that the client can not even send a KRB_AP_REQ.

Having a Application send a KRB_ERROR upon receiving an rfc-1964 AP_REQ
will result in fatal termination of the security context establishment
for every conforming implementation of rfc-1964.  So this suggestion
seems to create an interoperability problem, and the CONTINUE_NEEDED
status is an inappropriate return status for gss_accept_sec_context()
for a mechanism using the rfc-1964 mechanism OID.

-Martin

_______________________________________________
SPKM mailing list
SPKM@ietf.org
https://www1.ietf.org/mailman/listinfo/spkm