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

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 18 Aug 2009 13:47:48 -0700

I'm ok with all three change.

I don't see any text that the proxy needs to protect itself from  
unwanted realms in the message, that should be in the security  
considerations section.

Love

30 jul 2009 kl. 15:53 skrev Larry Zhu:

> 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

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

---

From: Larry Zhu <[email-masked]>
Date: Wed, 19 Aug 2009 04:07:28 +0000

Text was added into -02 to cover that. Can you see if it is sufficient?
   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, firewall 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.

http://www.ietf.org/id/draft-ietf-krb-wg-iakerb-02.txt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Love Hörnquist Åstrand
Sent: Tuesday, August 18, 2009 1:48 PM
To: Larry Zhu
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] Iakerb updates: issues and proposed changes

Love

---

From: Martin Rex <[email-masked]>
Date: Wed, 19 Aug 2009 21:16:57 +0200 (MEST)

Larry Zhu wrote:
> 
> The IAKERB ID has passed WGLC and is on its way to IESG. Base on recent
> 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.

Having the generic framing (with the IAKERB mechanism OID) on all context
level tokens is IMHO a good idea.

How about the tokens for protected messages (getmic/verifymic/wrap/unwrap)?
I assume that it should use the same token formats and conventions as
rfc-4121 (presence of generic framing for rfc-1964 message protection).
What about the mechanism OID in the generic framing of the rfc1964
protected messages?

Using the IAKERB mechanism OID for the rfc1964 protected messages
would be consistent if the security context was established with IAKERB.
Personally, I wouldn't mind of both OIDs would be OK.  Could you add
a sentence to the document what is expected (or required)?

-Martin

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Thu, 20 Aug 2009 03:29:34 -0700

Yes, that is sufficient. Thanks.

Love

18 aug 2009 kl. 21:07 skrev Larry Zhu:

> From: [email-masked] [mailto:ietf-krb-wg- 
> [email-masked]] On Behalf Of Love Hörnquist Åstrand