Kitten Meeting at IETF68 has been canceled

After speaking with our Security Area Director, Sam Hartman, it has been
decided that Kitten will not meet at IETF68.  Kitten will hold its next
meeting in Chicago at IETF69.

Jeffrey Altman
Kitten Chair

_______________________________________________
Kitten mailing list
Kitten <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/kitten

Last Call: draft-williams-on-channel-binding

I know it is in IETF last call (not WG last call) and I'm pretty late
(as always).

Section 2 Definitions
  o  Cryptographic bindings (bottom of page 5)

                                For example, a PKIX certificate binds a
      private key to the name of a principal in the trust domain of the
      certificate's issuer such that a possessor of said private key can
      act on behalf of the user (or other entity) named by the
      certificate.

A PKIX certificate binds a >>public key<< to the name of a principal,
NOT a private key.  The public key acts as a verifier for a cryptographic
proof-of-possession of a corresponding private key.
(And in the traditional PKI, there is no "act on behalf of" (=delegation),
the assumption is always always that he who can provide a proof that can
be verified with the public key it is the one and only rightful owner
asserted by the certificate.)

      (we don't say that a user speaks
      for their private keys, but we do say that the user's private keys
      speak for the user).

The private key is NEVER involved in anything the verifier does.

The assumptions surrounding the key pair and private key include
  - the keypair was correctly created
  - the private key is sufficiently protected from compromise
  - the owner doesn't compromise/publish the private key on purpose

Re: Comments on draft-zhu-pku2u-01.txt

Section 3

   If initially the initiator has a service ticket to the acceptor, the
   initiator, acting as the client in the parlance of [RFC4120],
   performs the client-server authentication exchange according to
   [RFC4121] and Section 3.2 of [RFC4120], with the acceptor acting as
   the server.

Why state this? In the motivation section, it has been stated that: 
"there is no trusted third party in such environments." While it is 
stated that "consequently the Kerberos protocol as defined in [RFC4120] 
and [RFC4556] is inadequate to provide security services ", this 
document's writing heavily depends on it and PKU2U is basically rfc4556 
where the server is not a KDC.

   If all goes well, processing the KRB_AS_REQ message will result in
   the creation of a ticket for the initiator to present to the acceptor
   and the response is a KRB_AS_REP message generated according to
   Section 3.1.3 of [RFC4120].

Isn't there a missing reference to the Section 3.2.3 of RFC4556. Unlike 
KDC and principal, acceptor and initiator don't share any secrets. 
PKINIT's PA_PK_AS_REP is needed here for the initiator to make use of 
the ticket created by the acceptor.

   In all cases, GSS_Accept_security_context() returns
   GSS_S_CONTINUE_NEEDED status [RFC2743] and the output token is a
   KRB_AS_REP message if a ticket was created or a KRB_ERROR message if
   there was an error while processing the request or the local policy
   prevented a ticket from being issued.

Re: Comments on draft-zhu-pku2u-01.txt

On Friday, March 16, 2007 04:52:40 PM -0400 Olga Kornievskaia 
<aglo <at> citi.umich.edu> wrote:

>    In all cases, GSS_Accept_security_context() returns
>    GSS_S_CONTINUE_NEEDED status [RFC2743] and the output token is a
>    KRB_AS_REP message if a ticket was created or a KRB_ERROR message if
>    there was an error while processing the request or the local policy
>    prevented a ticket from being issued.
>
> If the acceptor returns GSS_S_CONTINUE_NEEDED in the case of an error,
> what happens when the initiator after processing the error token decides
> to stop, will the server just hang there in the continue needed state?

This is a good point.  GSS_S_CONTINUE_NEEDED indicates that it will be 
necessary to make the call again with another token provided by the peer. 
When GSS_Init_sec_context or GSS_Accept_sec_context emits an error token, 
it should also return an appropriate error status, not 
GSS_S_CONTINUE_NEEDED.

> Token ids are defined for KRB_AS_REQ and KRB_AS_REP but not for KRB_ERROR?

The token ID for KRB_ERROR is defined in RFC 4121.

> Perhaps last paragraph of Section 6 can have a more detailed explanation
> that doesn't require the user to go search for a different draft to find
> our that AP_REQ should carry TYPED_DATA of type TD_IAKERB_FINISHED.  I'm
> sure i'm missing something but why is there a need to tie AS_REQ/REP to
> AP_REQ/REP no such ties exist in original Kerberos message flow?

RE: Comments on draft-zhu-pku2u-01.txt

Jeff wrote:
> This is a good point.  GSS_S_CONTINUE_NEEDED indicates that it will be

> necessary to make the call again with another token provided by the
peer. 
> When GSS_Init_sec_context or GSS_Accept_sec_context emits an error
token, 
> it should also return an appropriate error status, not 
> GSS_S_CONTINUE_NEEDED.

This is not necessary accurate. In the User2User protocol,
http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.tx
t,
the server can return a KRB_ERROR with the GSS_S_CONTINUE_NEEDED status.

-----Original Message-----
From: Jeffrey Hutzelman [mailto:jhutz <at> cmu.edu] 
Sent: Friday, March 16, 2007 2:34 PM
To: Olga Kornievskaia; Liqiang(Larry) Zhu
Cc: Michael.Eisler <at> netapp.com; andros <at> citi.umich.edu;
kitten <at> lists.ietf.org; spkm <at> ietf.org; Nicolas Williams; Jeffrey
Hutzelman
Subject: Re: Comments on draft-zhu-pku2u-01.txt

On Friday, March 16, 2007 04:52:40 PM -0400 Olga Kornievskaia 
<aglo <at> citi.umich.edu> wrote:

>    In all cases, GSS_Accept_security_context() returns
>    GSS_S_CONTINUE_NEEDED status [RFC2743] and the output token is a
>    KRB_AS_REP message if a ticket was created or a KRB_ERROR message

RE: Comments on draft-zhu-pku2u-01.txt

Olga Kornievskaia wrote:

> Why state this? In the motivation section, it has been stated that: 
> "there is no trusted third party in such environments." While it is 
> stated that "consequently the Kerberos protocol as defined in
[RFC4120] 
> and [RFC4556] is inadequate to provide security services ", this 
> document's writing heavily depends on it and PKU2U is basically
rfc4556 
> where the server is not a KDC.

This is designed for fast session resumption. When the initiator already
obtained a service ticket in prior sessions, it can just use that cached
ticket right away.

> Isn't there a missing reference to the Section 3.2.3 of RFC4556.
Unlike 
> KDC and principal, acceptor and initiator don't share any secrets. 
> PKINIT's PA_PK_AS_REP is needed here for the initiator to make use of 
> the ticket created by the acceptor.

RFC4556 updates RFC4120, unless there is something here specific to
RFC4556, I do not see the need here.

> Since this is a GSS API mechanism what about QoP handling and channel 
> bindings?

These are handled in the same way as described in RFC4121.

> This draft does not support non-Kerberos environments. By that I mean,

Re: Comments on draft-zhu-pku2u-01.txt

On Fri, Mar 16, 2007 at 07:01:09PM -0700, Liqiang(Larry) Zhu wrote:
> Jeff wrote:
> > This is a good point.  GSS_S_CONTINUE_NEEDED indicates that it will be
> 
> > necessary to make the call again with another token provided by the
> peer. 
> > When GSS_Init_sec_context or GSS_Accept_sec_context emits an error
> token, 
> > it should also return an appropriate error status, not 
> > GSS_S_CONTINUE_NEEDED.
> 
> This is not necessary accurate. In the User2User protocol,
> http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.tx
> t,
> the server can return a KRB_ERROR with the GSS_S_CONTINUE_NEEDED status.

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.

RE: Comments on draft-zhu-pku2u-01.txt

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.tx
t

    
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 
   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.

-----Original Message-----
From: Nicolas Williams [mailto:Nicolas.Williams <at> sun.com] 
Sent: Friday, March 16, 2007 8:27 PM
To: Liqiang(Larry) Zhu
Cc: Jeffrey Hutzelman; Olga Kornievskaia; Michael.Eisler <at> netapp.com;
andros <at> citi.umich.edu; kitten <at> lists.ietf.org; spkm <at> ietf.org
Subject: Re: Comments on draft-zhu-pku2u-01.txt

RE: Comments on draft-zhu-pku2u-01.txt

On Fri, 16 Mar 2007, Liqiang(Larry) Zhu wrote:

> 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
>    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.

While this is a token carrying a KRB_ERROR, it's not an "error token" in
the sense that we're talking about.  In the context of Olga's and my
comments, an "error token" is one which causes the peer to abort context
establishment and return an error status to its caller.  Such a token
should never be returned with GSS_S_CONTINUE_NEEDED, because no reply is
expected.

-- Jeff

Re: Comments on draft-zhu-pku2u-01.txt

On Sat, Mar 17, 2007 at 03:04:39AM -0400, Jeffrey Hutzelman wrote:
> On Fri, 16 Mar 2007, Liqiang(Larry) Zhu wrote:
> 
> > 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
> >    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.
> 
> While this is a token carrying a KRB_ERROR, it's not an "error token" in
> the sense that we're talking about.  In the context of Olga's and my
> comments, an "error token" is one which causes the peer to abort context
> establishment and return an error status to its caller.  Such a token
> should never be returned with GSS_S_CONTINUE_NEEDED, because no reply is
> expected.

The quoted text does not call this an error token.