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

From: Olga Kornievskaia <[email-masked]>
Date: Fri, 16 Mar 2007 16:52:40 -0400

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.

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?

Is having a MUST for PKINIT's EKUs too restrictive?

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

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

This draft does not support non-Kerberos environments. By that I mean, a 
Kerberos domain must exist and users of PKU2U must have Kerberos 
principal names.

Name type NT-X500-PRINCIPAL which is rfc2253 string representation of 
the distinguished name does not produce a canonical name.

What happens when the initiator rejects the AS-REP tokens sent by the 
acceptor (ie., fails to verify acceptor's certificate)?  Does it 
generate an error token?

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?

Naming needs work. Comments made about naming in SPKM3 apply here.

Liqiang(Larry) Zhu wrote:
> Here is the updated PKU2U. Please review it and see if it has addressed
> all concerns.
>
> Thanks,
>
> --Larry
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, February 27, 2007 3:50 PM
> To: [email-masked]
> Subject: I-D ACTION:draft-zhu-pku2u-01.txt 
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Public Key Cryptography Based User-to-User
> Authentication - (PKU2U)
> 	Author(s)	: L. Zhu, et al.
> 	Filename	: draft-zhu-pku2u-01.txt
> 	Pages		: 10
> 	Date		: 2007-2-27
> 	
> This document defines the public key cryptography based user-to-user
>    authentication protocol - PKU2U. This mechanism provides security
>    services in peer to peer networking environments without requiring a
>    trusted third party.  Furthermore, the binding of PKU2U for the
>    Generic Security Service Application Program Interface (GSS-API) per
>    RFC2743 is defined based on RFC4121.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-zhu-pku2u-01.txt
>
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body of 
> the message. 
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-zhu-pku2u-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-zhu-pku2u-01.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>   

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 16 Mar 2007 17:33:35 -0400

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

> AP_REQ/REP no such ties exist in original Kerberos message flow?

I'm not entirely sure what you're talking about here.  The AS exchange is 
tied to a later AP exchange via the session key; this is true whether the 
AS exchange results in a TGT or directly in some other service ticket. 
However, this does not protect the integrity of the plaintext portion of 
the AS exchange, and in particular of PA-DATA contained in the AS-REQ, and 
this is generally considered to be a shortcoming of the current AS 
exchange.  While this is likely to be fixed in the next update to the 
Kerberos protocol spec (see draft-ietf-krb-wg-rfc1510ter), it is also 
possible for a higher layer to perform an after-the-fact integrity check of 
the entire AS exchange, as IAKERB does.  Whether this is necessary or a 
good idea is, of course, up for discussion.

-- Jeff

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 16 Mar 2007 19:01:09 -0700

> it should also return an appropriate error status, not 

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:[email-masked]] 
Sent: Friday, March 16, 2007 2:34 PM
To: Olga Kornievskaia; Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; Nicolas Williams; Jeffrey
Hutzelman
Subject: Re: Comments on draft-zhu-pku2u-01.txt

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.

> AP_REQ/REP no such ties exist in original Kerberos message flow?

I'm not entirely sure what you're talking about here.  The AS exchange
is 
tied to a later AP exchange via the session key; this is true whether
the 
AS exchange results in a TGT or directly in some other service ticket. 
However, this does not protect the integrity of the plaintext portion of

the AS exchange, and in particular of PA-DATA contained in the AS-REQ,
and 
this is generally considered to be a shortcoming of the current AS 
exchange.  While this is likely to be fixed in the next update to the 
Kerberos protocol spec (see draft-ietf-krb-wg-rfc1510ter), it is also 
possible for a higher layer to perform an after-the-fact integrity check
of 
the entire AS exchange, as IAKERB does.  Whether this is necessary or a 
good idea is, of course, up for discussion.

-- Jeff

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 16 Mar 2007 19:45:05 -0700

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

> 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 

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

> Kerberos domain must exist and users of PKU2U must have Kerberos 

How was this deduced? What is a Kerberos domain? And it should not be
needed. what environments are not supported? Can you expand on this? 

> the distinguished name does not produce a canonical name.

PKU2U requires little endian order:

   The Distinguished Name contained in the
   PKU2U Kerberos principal name MUST begin with the most specific
   attribute and continue with progressively broader attrbiutes.

With this constraint, is there a case where this does not produce a
canonical name?

> acceptor (ie., fails to verify acceptor's certificate)?  Does it 

You can get an error token as in
http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.tx
t. but typically the acceptor returns an error and aborts.

> Naming needs work. Comments made about naming in SPKM3 apply here.

Can you point me to the comments, it would help. Thanks for the review.

--larry
-----Original Message-----
From: Olga Kornievskaia [mailto:[email-masked]] 
Sent: Friday, March 16, 2007 1:53 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; Nicolas Williams;
[email-masked]; [email-masked]
Subject: Re: Comments on draft-zhu-pku2u-01.txt

Section 3

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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 16 Mar 2007 22:26:43 -0500

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

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 16 Mar 2007 22:37:24 -0700

> 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:[email-masked]] 
Sent: Friday, March 16, 2007 8:27 PM
To: Liqiang(Larry) Zhu
Cc: Jeffrey Hutzelman; Olga Kornievskaia; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: Comments on draft-zhu-pku2u-01.txt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 17 Mar 2007 03:04:39 -0400 (EDT)

>    GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism

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

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 18 Mar 2007 07:20:27 -0500

> should never be returned with GSS_S_CONTINUE_NEEDED, because no reply is

The quoted text does not call this an error token.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 18 Mar 2007 19:23:50 -0400 (EDT)

> The quoted text does not call this an error token.

No, it doesn't, but check the current thread.  The current PKU2U document
indicates that "In all cases, GSS_Accept_security_context returns
GSS_S_CONTINUE_NEEDED... a KRB_ERROR if there was an error...".  Olga's
reading and mine is that this in some cases requires returning
GSS_S_CONTINUE_NEEDED with an output token that is an "error token" as I
define it above; that is, one which the initiator is expected to handle by
aborting the context establishment (Olga didn't use the phrase "error
token", but I did).

Larry quoted the text from section 6 of the Kerberos U2U as a
counterexample to my argument that when an error token is emitted, it
should always come with a real error code, not GSS_S_CONTINUE_NEEDED.  But
the quoted text is not actually a counterexample, because although the
token described containes a KRB-ERROR, it is not an "error token"; it is
intended to trigger the U2U mechanism, which will result in another
context token.

The case described on page 5 of PKU2U-01 describes a token produced when
"there was an error while processing the request or the local policy
prevented a ticket from being issued."  These are situations in which
context establishment cannot continue, and the error token is intended to
cause GSS_Init_sec_context to return an appropriate failure code.  Since
no further tokens are expected, the correct result code is something other
than GSS_S_CONTINUE_NEEDED.

More generally, a mechanism should return GSS_S_CONTINUE_NEEDED in exactly
those cases where the peer is expected to send another token, and no
others.

-- Jeff

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sun, 18 Mar 2007 16:43:06 -0700

The intention of the text in -01 is that if a KRB-ERROR message should
be generated according to rfc4120, then GSS_S_CONTINUE_NEEDED MUST be
returned. 
Based on the discussion here, the draft should acknowledge cases where
there is an error that is not a KDC error per RFC4120, say for example
the acceptor runs out of memory.
 
> those cases where the peer is expected to send another token, and no
Would it be preferable to return a GSS_S_CONTINUE_NEEDED and a KRB_ERROR
in cases where the client is not expected to send another token, for
example in the case of a policy error? The error message contains useful
information for trouble-shooting. 	

I would not recommend returning an error token when the returned status
is NOT GSS_S_CONTINUE_NEEDED, in that cases, most apps would simply
throw that away.
--larry
-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Sunday, March 18, 2007 4:24 PM
To: Nicolas Williams
Cc: Liqiang(Larry) Zhu; Olga Kornievskaia; [email-masked];

> The quoted text does not call this an error token.

No, it doesn't, but check the current thread.  The current PKU2U
document
indicates that "In all cases, GSS_Accept_security_context returns
GSS_S_CONTINUE_NEEDED... a KRB_ERROR if there was an error...".  Olga's
reading and mine is that this in some cases requires reinturning
GSS_S_CONTINUE_NEEDED with an output token that is an "error token" as I
define it above; that is, one which the initiator is expected to handle
by
aborting the context establishment (Olga didn't use the phrase "error
token", but I did).

should always come with a real error code, not GSS_S_CONTINUE_NEEDED.
But

The case described on page 5 of PKU2U-01 describes a token produced when
"there was an error while processing the request or the local policy
prevented a ticket from being issued."  These are situations in which
context establishment cannot continue, and the error token is intended
to
cause GSS_Init_sec_context to return an appropriate failure code.  Since
no further tokens are expected, the correct result code is something
other
than GSS_S_CONTINUE_NEEDED.

More generally, a mechanism should return GSS_S_CONTINUE_NEEDED in
exactly
those cases where the peer is expected to send another token, and no
others.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 18 Mar 2007 19:44:29 -0400 (EDT)

> be generated according to rfc4120, then GSS_S_CONTINUE_NEEDED MUST be

Why?  How does the initiator handle these tokens?  If it does so in any
way other than by producing a new token, then the acceptor should not be
returning GSS_S_CONTINUE_NEEDED.

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sun, 18 Mar 2007 16:50:30 -0700

> returning GSS_S_CONTINUE_NEEDED.

The deployment experience shows that if the client (instead of the
acceptor or the KDC) can log the error information, the cost of trouble
shooting is significantly lower.

If the acceptor returns a KRB_ERROR message with a status that is
anything but GSS_S_CONTINUE_NEEDED, there is no guarantee and it is in
fact very unlikely that the trouble-shooting information can make it to
the client side in order to get logged.

--larry

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Sunday, March 18, 2007 4:44 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; Nicolas Williams; [email-masked];
[email-masked]; [email-masked]
Subject: RE: Comments on draft-zhu-pku2u-01.txt

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 18 Mar 2007 19:58:50 -0400 (EDT)

> the client side in order to get logged.

No; you are confused.  GSS_S_CONTINUE_NEEDED does not mean "there is a
token to send to the peer".  It means "another token is expected from the
peer".  Any token produced by GSS_Accept_sec_context should be sent to the
peer regardless of the returned status code.

Behaving otherwise violates the abstraction and will break application
protocols which expect the GSS-API to behave as specified, regardless of
which mechanism is being used.

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Mar 2007 16:25:34 +0100 (MET)

Liqiang wrote:
> http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.txt,

Returning a KRB_ERROR token along with GSS_S_CONTINUE_NEEDED minor_status
from gss_accept_sec_context() is defintely *NOT* allowed by rfc-1964.

There seems to be text describing a backward incompatible change in
rfc-4121 last paragraph of section 4.1, (top of page 5) which
allows such misbehaviour for the specific case of an unknown token ID:

   If an unknown token identifier (TOK_ID) is received in the initial
   context establishment token, the receiver MUST return
   GSS_S_CONTINUE_NEEDED major status, and the returned output token
   MUST contain a KRB_ERROR message with the error code
   KRB_AP_ERR_MSG_TYPE [RFC4120].

But since the spec is entirely silent about how the client can continue
to produce a successful security context establishment from that point on,
it is sufficiently incomplete to be unusuable.

SSPI has been returning KRB_ERROR tokens along with CONTINUE_NEEDED
status from the beginning, in an undocumented/unspecified fashion,
non-interoperable with rfc-1964 based Kerberos implementations.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Mar 2007 16:38:04 +0100 (MET)

> the server can return a KRB_ERROR with the GSS_S_CONTINUE_NEEDED status.

IIRC, the user2user implementation shipped by Microsoft uses a
mechanism OID different from rfc-1964/rfc-4121.

Technically, the "context establishment handshake" is opaque to the 
application.  It is conceivable to define a context establishment handshake
that negotiates (optional) features in multiple steps, and the names
of intermediate tokens are just an implementation detail.  However, the spec
of a mechanism ought to be sufficiently clear that everyone can implement
optional multi-step negotiations reliably in an interoperable fashion.

Retrofitting KRB_ERROR + CONTINUE_NEEDED for rfc-1964 and successors
should NOT break implementations based on the original specs,
which likely do not support this.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Mon, 19 Mar 2007 12:13:22 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> On Sun, 18 Mar 2007, Liqiang(Larry) Zhu wrote:
    >> Jeffrey Hutzelman wrote: > Why?  How does the initiator handle
    >> these tokens?  If it does so in any > way other than by
    >> producing a new token, then the acceptor should not be >
    >> The deployment experience shows that if the client (instead of
    >> the acceptor or the KDC) can log the error information, the
    >> cost of trouble shooting is significantly lower.
    >> 
    >> If the acceptor returns a KRB_ERROR message with a status that
    >> is anything but GSS_S_CONTINUE_NEEDED, there is no guarantee
    >> and it is in fact very unlikely that the trouble-shooting
    >> information can make it to the client side in order to get
    >> logged.

    Jeffrey> No; you are confused.  GSS_S_CONTINUE_NEEDED does not
    Jeffrey> mean "there is a token to send to the peer".  It means
    Jeffrey> "another token is expected from the peer".  Any token
    Jeffrey> produced by GSS_Accept_sec_context should be sent to the
    Jeffrey> peer regardless of the returned status code.

    Jeffrey> Behaving otherwise violates the abstraction and will
    Jeffrey> break application protocols which expect the GSS-API to
    Jeffrey> behave as specified, regardless of which mechanism is
    Jeffrey> being used.

I strongly agree with Jeff here.

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Mar 2007 17:23:26 +0100 (MET)

Liqiang wrote:
> http://www.watersprings.org/pub/id/draft-swift-win2k-krb-user2user-03.txt
> 
>     

Is it me or should this read KRB_AP_REQ? 

>    GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism 

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

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Mar 2007 17:29:08 +0100 (MET)

> peer regardless of the returned status code.

Actually, that is not completely accurate.

An application that obtains a context token along with a fatal routine
error from one of the context establishment calls (gss_accept_sec_context
or gss_init_sec_context) is *NOT* required to send this to the peer.
It may do so, but it may also shutdown the communication channel.
I expect that a lot of applications will not actually send such a token
(ours doesn't).

> which mechanism is being used.

Returning CONTINUE_NEEDED status when the mechanism spec does *NOT*
define a clear method how to continue the context establishment
handshake to successful completion is broken on my scorecard.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Mar 2007 18:10:54 +0100 (MET)

> those cases where the peer is expected to send another token, and no

I fully agree.

Engineering-wise it is a pretty bad idea to cause (server) applications
to keep unnecessary state around (a proto security context that will
never get established) and remain tied up in the security context
establishment loop of the GSS-API security context establishment
exchange unless there is a real possibility that the handshake
on this security context will be continued and lead to a successful
completion.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Mar 2007 18:31:51 +0100 (MET)

> shooting is significantly lower.

I do not agree.

(OT: You might want to convince the MSIE/schannel maintainers,
 currently you need a debugger to figure our the SSL alert received
 by MSIE, MSIE itself presents just a useless "it may everything including
 sunspots" error messages, and its been doing this for 10 years).

> the client side in order to get logged.

IMHO, that is more of an application problem than a Kerberos problem.
With your approach, the error and all details will completely hidden
from the Server and Server admins.   I consider it a real problem
when the error is NOT locally reported where it occurs.

Whether and how much a client can do for trouble-shooting may
be application specific!  When helpdesk is called, the only
information that is reliably available/accessible is that
logged centrally on backends/servers.

E.g. when my application notices a "wrong target name in request"
type of error, it aborts the security context establishment
and returns an error message at the "application level" conveying
this error along with the name that the server uses for acquiring
his own credentials.  (since some gssapi mechanisms are poor at
determining this error, my application framing protocol sends
the target name along with the initial context establishment token
and when gss_accept_sec_context() fails with an error it compares
the accompanying target name with its own server name in order
to decide whether it sends a "wrong target name" application level
error message back to the client.

-Martin

> SPKM mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/spkm
>

---

From: Olga Kornievskaia <[email-masked]>
Date: Mon, 19 Mar 2007 14:22:20 -0400

> obtained a service ticket in prior sessions, it can just use that cached
Ok. However, I think that it makes more sense to explain the initial 
step first (ie., when no security context has been established between 
the parties), then explain the case of reusing previously acquired 
credentials.
>> 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.    
The doc states that:

   The initiator always includes the PA_PK_AS_REQ pre-authentication data computed according
   to Section 3.2.1 of [RFC4556].

I might be wrong but I believe that the reply message contains 
PA_PK_AS_REP pre-auth data as pre Section 3.2.2 of rfc4556. If not, 
ignore my comment. Otherwise, I think clarifying that the reply is not 
simply AS_REP is important.
>> This draft does not support non-Kerberos environments. By that I mean, a Kerberos domain must exist and users of PKU2U must have Kerberos principal names.
>>     
Naming of PKU2U participants is defined in terms on Kerberos name forms. 
Like SPKM3, PKU2U does not assume that the initiator knows the 
acceptor's certificate (at least there is nothing in the spec that says 
otherwise). Thus, the initiator needs to create/invent a name for the 
acceptor and include it in the AS_REQ. The document assume that the name 
would be in a Kerberos form. At this point, the likelihood that the 
initiator can create a correct KRB_NT_500_PRINCIPAL name that would 
eventually be matched to the DN in the acceptor's certificate is low. 
Thus, the other option is to create a typical Kerberos name 
"principal_name/instance@realm". The set of "principal_name/instance" 
names in a given "realm" constitutes a Kerberos domain. Such names must 
have been established and existed prior the initiator and acceptor's 
communication.

Now that I think about it, I have a question as to how would 
identification verification work when the certificate say don't have a 
SAN with principal_name in them? How would you match the 
"name/instance@realm" name to a DN?

> With this constraint, is there a case where this does not produce a
One example is multi-valued RDNs. I might be wrong but wasn't there a 
problem (in practice) of having different "string" names for RDN OIDs 
(or different implementations not knowing a mapping from an oid to a 
string name of an RDN, thus leading to different string representations).

> Can you point me to the comments, it would help. 
I just realized that the discussion I was referring to occurred prior to 
the creation of the spkm mailing list. Thus, it was a private discussion 
that included comments from Nico Williams and Martin Rex.

---

From: Olga Kornievskaia <[email-masked]>
Date: Mon, 19 Mar 2007 16:09:49 -0400

> I expect that a lot of applications will not actually send such a token
I agree with Jeff that GSS_S_CONTINUE implies another token is coming. I 
also agree with Martin and disagree with Jeff on the issue of handling 
an output token when gss_accept_sec_context() fails. What I would like 
to highlight is the fact that the current draft requires serious 
clarifications when it comes to handling error cases!

GSS API guarantees that an output will be sent if the GSS_S_CONTINUE is 
returned. Thus if you want to convey error details (KRB-ERROR) to your 
peer, then you should return GSS_S_CONTINUE. However this brings me back 
to my original point that the server is left hanging (ie, keeping 
state). As others pointed out, using up resources on the server is not 
desirable.

As I was looking at error tokens in GSS API in general (and also related 
to SPKM3), I was scratching my head trying to figure out how can one 
make use of error tokens as in any GSS mechanism they seem to present 
the problem we are discussing right now. I came to the conclusion that 
error tokens can't be used and we just have to do with error status 
codes. Therefore, I think this spec should be changed to say that on 
failure an error code should be returned instead of the GSS_S_CONTINUE. 
I'm not sure whether or not saying the following is beneficial: that 
KRB-ERROR token could be returned as well but it is up to the GSS 
application to decide whether such output token is sent to the peer.

> handshake to successful completion is broken on my scorecard.
Agreed!

---

From: Olga Kornievskaia <[email-masked]>
Date: Mon, 19 Mar 2007 16:45:28 -0400

If we had GSS TSL (or SPKM3), a security context can be established 
between an anonymous client and a server with a certificate. If that 
possible with PKU2U?

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 19 Mar 2007 14:10:59 -0700

Yes, this is a supported mode, the client/initiator is anonymous and the
acceptor has a certificate.

-----Original Message-----
From: Olga Kornievskaia [mailto:[email-masked]] 
Sent: Monday, March 19, 2007 1:45 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; Nicolas Williams
Subject: Re: FW: I-D ACTION:draft-zhu-pku2u-01.txt

---

From: Olga Kornievskaia <[email-masked]>
Date: Mon, 19 Mar 2007 18:15:23 -0400

Do you plan to extend the current document and include the details of 
this case?

Liqiang(Larry) Zhu wrote:
>> Here is the updated PKU2U. Please review it and see if it has
>>     
> addressed
>   
>> all concerns.
>>
>> Thanks,
>>
>> --Larry
>>
>>    services in peer to peer networking environments without requiring
>>     
> a
>   
>>    Generic Security Service Application Program Interface (GSS-API)
>>     
> per
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 20 Mar 2007 07:32:39 -0400 (EDT)

> I expect that a lot of applications will not actually send such a token

Well, that depends on the specification of the application - some
application protocols are as you describe, and some dictate one choice or
the other.  But the key point here is that CONTINUE_NEEDED means that a
token is expected from the peer, and should not be returned otherwise.

> handshake to successful completion is broken on my scorecard.

Agree.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 20 Mar 2007 07:37:57 -0400 (EDT)

> logged centrally on backends/servers.

That is true only if the helpdesk is associated with the people operating
the servers, rather than the people supporting the user.  OFten these are
not the same organization, and the only information available is that
recorded on the client.

If one of my users reports a problem talking to some remote site, I can,
if necessary, examine error logs, attach a debugger to their client,
and/or observe the traffic on the wire.  Actually getting error data from
the server can be essential to making this work.

That said, applications should be designed to correctly carry error tokens
without requiring that they be returned with GSS_S_CONTINUE_NEEDED,
because no mechanism should be doing that.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 26 Mar 2007 14:18:12 -0400

>    KRB_AP_ERR_MSG_TYPE [RFC4120].

That looks to me like an error in RFC4121.  Clearly the status in this case 
should not be GSS_S_CONTINUE_NEEDED.

> non-interoperable with rfc-1964 based Kerberos implementations.

Oh, it interoperates, because initiators respond to the KRB-ERROR by 
returning an error, so the application gives up and never sends a token 
back.  The problem is that returning GSS_S_CONTINUE_NEEDED in this case is 
likely to confuse a GSS-API application on the acceptor side, because it 
expects to receive another token from the client.  OTOH, since you're 
describing the behavior of SSPI, not GSS-API, and CONTINUE_NEEDED is an API 
construct, this situation is perfectly fine -- SSPI can establish different 
(even broken) semantics for its applications, and an API translation module 
such as the one you maintain will have to deal.  I'd assume you would do 
this by "knowing" when the mechanism is Kerberos, peeking inside the token, 
and turning GSS_S_CONTINUE_NEEDED into something else if the token is a 
KRB-ERROR token.  Ugly, but perhaps necessary.

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Tue, 27 Mar 2007 00:44:24 +0200 (MET DST)

> should not be GSS_S_CONTINUE_NEEDED.

In principle, such an extension would be OK, provided that the spec
was sufficiently clear to provide a fallback continuation of the
security context handshake.

Compliant gss-api mechanisms are not normally sending context tokens with
an unknown TOK_ID, so this change should --in theory-- not break existing
conforming implementations.

I don't remember that such a change was ever discussed, and I consider
it significantly underspecified and hidden.

> back.

I know that the KRB_ERROR token is part of rfc1964 and understood
by rfc1964 peers, but that is not what I meant.

The interoperability that I was refering to was not the indication
of an error, but the attempt of recovery that Microsoft has built
into their Kerberos SSP and for which the CONTINUE_NEEDED is necessary.
Microsoft's Kerberos SSP will perform a second attempt to establish
the security context on the same security context handle with another
token exchange--and on this feature the other Kerberos 5 implementations
will likely not interoperate (because it is not standardized anywhere).

> The problem is that returning GSS_S_CONTINUE_NEEDED in this case is 
> (even broken) semantics for its applications,

They can and they do use semantics for SSPI that differ from GSS-API,
but that makes them non-conforming to rfc-1964/rfc-4121.
(they still use the same wire-format, but the GSS-API standard
includes API semantics, not just mechanism wire-format.

> An API translation module 

Yup, that's what it will have to do.

My wrapper is currently limited to rfc-1964 Kerberos, so it aborts
on user2user context establishment tokens and aborts with an error
when AcceptSecurityContext returns CONTINUE_NEEDED (because rfc-1964
is limited to 1- and 2-token context establishment handshakes).

Another interoperability problem with Microsoft Kerberos is the
security context lifetime limit required by rfc-1964.
When Microsoft tried to activate that in Windows 2000 beta3
hell broke loose because none of their applications could handle
expiring security contexts.  So they deliberately ignore it.
My gssapi wrapper adds this back in, so that you have consistent
behaviour within the entire Kerberos5 infrastructure.

-Martin