Subject: [Ietf-krb-wg] Iakerb updates: issues and proposed changes

From: Larry Zhu <[email-masked]>
Date: Thu, 30 Jul 2009 22:53:24 +0000

The IAKERB ID has passed WGLC and is on its way to IESG. Base on recent
implementation experience, we would like to propose 3 changes to -01.

1) The issue: the encoding of subsequent tokens is inconsistent with RFC4121.
This creates unnecessarily high implementation costs. We would like to specify
that all the context tokens have the pseudo ASN.1 header to be consistent with
RFC4121.

2) The issue: the text in -01 is not explicit about how the server fills out
the header in the IAKERB response. Although one can deduce how this works,
it would be helpful to simply clarify it as follows:

   The GSS-API server encapsulates the KDC reply message in the returned
   IAKERB message.  It fills out the target realm using the realm sent
   by the client and the KDC reply message is included immediately
   following the IAKERB-HEADER header.

   The client and the server can repeat the sequence of sending and
   receiving the IAKERB messages as described above, in order to allow
   the client interact with the KDC through the IAKERB proxy, and to
   obtain Kerberos tickets as needed.

3) The issue: it is not clear how to support client referrals using an enterprise
name on a client host that is not joined to a Kerberos realm. We would like to
propose to allow the client to retrieve the server's Kerberos realm and use that
as the starting point to resolve an enterprise name. Here is the proposed text.

   When obtaining the initial TGT, the client may start with an NT-
   ENTERPRISE name type and the client host does not have a Kerberos
   realm.  To resolve the NT-ENTERPRISE name type, the client typically
   starts with the client host realm and then finds out the true realm
   of the client based on [REFERALS].  In this case the GSS-API client
   can retrieve the realm of the GSS-API server as follows: the client
   returns GSS_S_CONTINUE_NEEDED with the output token containing an
   IAKERB message with an empty target-realm in the IAKERB-HEADER and no
   Kerberos message following the IAKERB-HEADER structure.  Upon receipt
   of the realm request, the GSS-API server fills out the target realm
   field using the realm of the server, and returns
   GSS_S_CONTINUE_NEEDED with the output token containing the IAKERB
   message with the server's realm and no Kerberos message following the
   IAKERB-HEADER header.  The GSS-API client can then use the returned
   realm in subsequent IAKERB messages to resolve the NT-ENTERPRISE name
   type.  Since the GSS-API server can act as a Kerberos acceptor, it
   always has a Kerberos realm in this case.

Once these changes are approved, we can submit -02 to reflect the implementation
experience described here.

--Larry
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 30 Jul 2009 21:19:52 -0400

> implementation experience, we would like to propose 3 changes to -01.

That's slightly overstating the situation.  The WGLC certainly ended, and 
only one comment was raised.  However, I've not done a review or writeup 
yet, so it's actually more stalled than on its way anywhere. :-)

The one comment was from Love, on the question of how the proxy protects 
itself from unwanted traffic.  There was some discussion but I didn't 
actually see a resolution.  Please make sure when you submit an updated 
draft that this issue is resolved.

> Once these changes are approved, we can submit -02 to reflect the
> implementation experience described here.

I assume that other than resolving Love's comment and the three issues you 
mentioned in this message, you're not planning on making any other changes. 
I would appreciate comments from the WG on any of the proposed changes; 
anyone wishing to comment should do so or let me know you need more time no 
later than Friday, Aug. 7.

-- Jeff

---

From: Larry Zhu <[email-masked]>
Date: Fri, 31 Jul 2009 01:26:12 +0000

With regarding to the last call comment, as far as I remember, love agreed to the changes proposed in the attached although that agreement might be a verbal one in IETF sessions. I will double check with Love and ask him to confirm on the list. And -02 will contain the changes in the security consideration section. Thanks,

--Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Hutzelman
Sent: Thursday, July 30, 2009 6:20 PM
To: Larry Zhu; [email-masked]
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] Iakerb updates: issues and proposed changes

-- Jeff

Subject: RE: [Ietf-krb-wg] Re wglc of draft-ietf-krb-wg-iakerb-01
From: Larry Zhu <IMCEAEX-_O=MICROSOFT_OU=FIRST+20ADMINISTRATIVE+20GROUP_CN=RECIPIENTS_CN=[email-masked]>
To: 'Jeffrey Hutzelman' <[email-masked]>,'Love Hörnquist Åstrand' <[email-masked]>, 'Kerberos-wg -' <[email-masked]>
Date: Tue, 24 Mar 2009 21:31:49 +0000

How about:

To reduce attack surface, IP filters can be applied to allow from
which hosts the client requests can be proxied and the proxy can
further restrict the set of realms to which the requests
can be proxied.

--larry

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]]
Sent: Tuesday, March 24, 2009 2:14 PM
To: Larry Zhu; Love Hörnquist Åstrand; Kerberos-wg -
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] Re wglc of draft-ietf-krb-wg-iakerb-01

--On Tuesday, March 24, 2009 01:37:41 PM -0700 Larry Zhu
<[email-masked]> wrote:

> Hi Love
>
>> I think the draft does not explain how the proxy protects itself
>> agaist unwanted traffic, how the proxy only allow kerberos traffic but
>> not any other encrypted kerberos like traffic.
>
> The IAKERB proxy just forwards the request to port 88 of the targeted
> DCs. It does not handle any other traffic. Can you expand the comments if
> I did not fully understand your concern?
>
> Can I address your comments by adding the following text in the security
> considerations section?
>
> In section 5, I propose to replace OLD:
>
>    Similar to other network access protocols, IAKERB allows an
>    unauthenticated client (possibly outside the security perimeter of an
>    organization) to send messages that are proxied to interior servers.
>
> With NEW:
>
>    Similar to other network access protocols, IAKERB allows an
>    unauthenticated client (possibly outside the security perimeter of an
>    organization) to send messages that are proxied to interior servers.
> To reduce attack surface,    IPSEC filters can be applied to allow from
> which hosts the client requests can be proxied    And the proxy can
> additionally restrict to which realms the requests can be proxied.
>
> Note that only the last sentence is new and it is appended to the end of
> the existing paragraph. Does this fully address your concern?

I think by "IPSEC" here you mean some Microsoft host firewall thing.  In
the IETF, "IPsec" means the security extensions for IP, and talking about
"IPSEC filters" is almost certainly going to confuse someone.

-- Jeff