Subject: Working Group Last call - draft-ietf-cat-iakerb-07.txt

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 02 Jul 2001 14:08:35 -0500

A revised version of the IAKERB document is now ready for Working Group 
Last Call. 

        Title           : Extending the GSS Kerberos Mechanism for Initial      
                          Kerberos Authentication (IAKERB)
        Author(s)       : M. Swift, J. Trostle, B. Aboba, G. Zorn
        Filename        : draft-ietf-cat-iakerb-07.txt
        Pages           : 9
        Date            : 28-Jun-01

The draft can be found at:

http://www.ietf.org/internet-drafts/draft-ietf-cat-iakerb-07.txt

This document has had minor changes from the last revision, and the authors
will be sending out to the list of changes shortly. 

We will start a two week last call, which should end on July 18. 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Jonathan Trostle <[email-masked]>
Date: Mon, 02 Jul 2001 14:57:02 -0700

Some of the changes since the last version are:

(1) two new error codes from IAKERB proxy to the client for (a) if KDC
can't be located (b) KDC doesn't respond (K. Raeburn suggestion)

(2) fixed message names

(3) additional message processing description

(4) fixed definition of TKT_PUSH message

(5) added OID's, drafts cited as works in progress.

Jonathan

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 09 Jul 2001 10:39:08 -0500

We are still in last call on this document, so far I have only seen one
comment and that was from the author. 

--

---

From: Ken Raeburn <[email-masked]>
Date: 10 Jul 2001 17:25:10 -0400

> comment and that was from the author. 

I looked it over.

The only real comment I had this time around, which I've already sent
to Jonathan, was to note that IAKERB in combination with
krb-dns-locate may give an outsider a way to get a message to an
arbitrary port on an arbitrary machine, where the message is partly
under the outsider's control.  (Think about a realm listing a KDC on
127.0.0.1 TCP port 25, and a principal name like "<cr><lf>HELO
foo.com<cr><lf>MAIL FROM:[email-masked]<cr><lf>... you're all fired ..."
in that realm.)  UDP services might be harder to "attack" this way,
largely because it's mostly TCP ones that will let you send garbage
they don't recognize (the Kerberos ASN.1 goop) and will still act on
following commands (the principal name) in the same exchange, but
jumbograms can still be sent to try to overrun buffers.  It's not
going to be the first thing the script kiddies add to their toolkits,
but for someone making a serious effort to crack a particular host, it
would be something to explore.

The same can be done to a lesser degree without the krb-dns-locate
support, if the client still does hostname resolution, but the
attacker doesn't get control over the port number.  I still think
requiring Kerberos to always use port 88 would be a bad idea, but I'm
a little less sure of myself now... :-)

It's not an attack against the IAKERB server itself, nor a specific
attack against anything else.  But it may allow the IAKERB server to
be used in attacks on random other services.

Just what the best way is to fix this, I don't know.  Administratively
limiting the realms that can be contacted, or allowable client
addresses (IP, MAC or otherwise), might help.

Ken

---

From: Martin Rex <[email-masked]>
Date: Wed, 11 Jul 2001 16:33:07 +0200 (METDST)

>         Filename        : draft-ietf-cat-iakerb-07.txt

I see a new ASN.1 structure in this document:

     KRB_TKT_PUSH :: = [APPLICATION 17] SEQUENCE {
       pvno[0]             INTEGER,  -- 5 (protocol version)
       msg-type[1]         INTEGER,  -- 17 (message type)
       ticket[2]           Ticket
     }

however there's no mentioning how this structure should be encoded.
It might be a good idea to mention and require ASN.1 DER encoding ...

I do *strongly* object to the use of distinct gssapi mechanism
OIDs for "IAKERB proxy" and "IAKERB minimal messages", since
this would *require* the use of SPNEGO!  

No gssapi mechanism spec should require the presence of SPNEGO,
and since this document currently defines 2 gssapi mechanism oids
different from the Kerberos 5 GSS-API mechanism, it is in fact
a gssapi mechanism spec (even when it's incomplete by itself).

Quoting from the draft:

   A compliant IAKERB proxy MUST implement the IAKERB proxy protocol,
   and MAY implement the IAKERB minimal message protocol. In general,
   the existing Kerberos paradigm where clients contact the KDC to
   obtain service tickets should be preserved where possible.

The base GSS-API simply doesn't provide any negotiation or fallback
among gssapi mechanisms.  Since the two gssapi mechanisms are identified
by a different mechanism OID it is silly to say "1 is a must, 2 is a may".
When SPNEGO is used, then what mechanisms are offered are totally
at the discretion of the application that drives SPNEGO.
It would be clearly inappropriate for this spec to require
the "IAKERB proxy" mechanism to be included in the SPNEGO mechanism
list whenever the "IAKERB minimal messages" mechanism is in that list. 

SPNEGO is a means for admins to mix and match gssapi mechanisms,
it is absolutely wrong for gssapi mechanism to preclude presence
of SPNEGO or request constraints on the contents of that negotiation.

The two schemes "IAKERB proxy" and "IAKERB minimal messages"
should definitely be folded into a single mechanism.  At that level
it can be decided by the initiator which schemes to offer and at the
acceptor which schemes to accept.  At this level a must/may for
a particular combination is acceptable.

What seems to be missing in the document are means how
to determine and select which method should be used, and whether
the decision can be (or should be?) done by the application and
how the application would perform the selection.  Remeber that
GSS-API is both, a clear-cut API with a promise for applications
and mechanism specs for on-the-wire interoperability.
This spec only has the on-the-wire interoperability issues covered
and still lacks information to cover the API/behaviour promise.

Preferably the selection among "IAKERB proxy" and "IAKERB minimal messages"
should be a local decision internal to the Kerberos gssapi mechanism
so that "portable" applications will be able to use it.  Otherwise
there is little merit is making this look like a gssapi mechanism.

Ideally this spec would even reuse the Kerberos 5 mechanism OID
and just distinguish the procotol with the token ID of the inner token.
Unfortunately there is no clear warning in rfc1964 that requires
Kerberos gssapi mechanism implementations that they must deal with
unrecognized token ids in a sensible way (i.e. clear error message,
no GPV/core dumps) to allow forward compatibility to future extensions.
This approach would ultimately require the mechanism to select
internally among "IAKERB proxy" and "IAKERB minimal messages".

Note however that with GSS-API there is *no* "failback" mode!
SPNEGO is a negotiation on top of other gssapi mechanisms.
When the acceptor doesn't implement SPNEGO (i.e. all of the
currently installed base), then the application will abort
when the client tries it.

Regular (portable) gssapi-based applications will make exactly
one attempt to establish a security context and will terminate
in some unspecified fashion when this context establishment fails.
For the majority of applications, the initiator will notice some kinds of
context establishment failures (like "unknown mechanism") by
premature closure of the communication channel by the acceptor.
Acutally, this is why SPNEGO was defined at all, so that
independent mechanisms could be negotiated and tried without showing
a failure at the gssapi level.  Anyway, for the task at hand I am
convinced that a requirement for SPNEGO in this spec is overkill.

-Martin

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 12 Jul 2001 09:57:55 -0500

Ken, 
I am trying to understand your attack.

Ken Raeburn wrote:

> 127.0.0.1 TCP port 25, 

Would a realm really use a well know port like 25? Or is this because
the attacker can spoof the DNS and have it ruturn this address and port?
Is this a more general problem with the DNS locate, rather then just IAKERB?

> and a principal name like "<cr><lf>HELO
> in that realm.) 

Could the IAKERB server do any sanity checks on the principal name?
Are <cr><lf> valid in a principal?

> UDP services might be harder to "attack" this way,

Would these be considered implementation details, and not protocol issues?

--

---

From: Ken Raeburn <[email-masked]>
Date: 12 Jul 2001 13:55:13 -0400

> Is this a more general problem with the DNS locate, rather then just IAKERB?

I would not expect it to be used normally, but if the port number can
vary and if the DNS SRV record can be spoofed, how many well-known
ports should we filter out?  Granted, most KDCs will be on port 88,
but I still think it'd be bad to require that.

I think it's a problem with the combination of the two.  With DNS SRV
alone, an active attacker could trick a client into sending to an
arbitrary host/port, but the message would not be under the attacker's
control at all, so it's not all that interesting.  (I think this'll be
the case for any service using DNS SRV, not just Kerberos.)  With
IAKERB alone, the attacker has some control over the message contents,
but almost none over where the proxy should send the message (it has
to be a KDC), also not that interesting.  With DNS spoofing but not
DNS SRV, any host could be the target, but only on port numbers listed
with the proxy as associated with some KDC.  (E.g., if I use port 79
for my KDC, the IP address lookup could be spoofed.)

> Are <cr><lf> valid in a principal?

It could, yes.  The <cr><lf> sequence might be valid, but a realm
admin would be crazy to actually use such names. :-)

However, there are other fields (preauth, in particular) where it
would be harder to enforce sanity checks, especially if the proxy
wants to support clients using preauth schemes that the proxy itself
doesn't know about (and shouldn't need to).  And if the attacker is
trying some sort of buffer-overrun attack, the <cr><lf> may not be
part of it anyways.

> Would these be considered implementation details, and not protocol issues?

The specific details of how to limit the exposure would be up to the
implementation, but the issue itself is likely to come up for anyone
implementing the protocol (at least, anyone implementing this *and*
krb-dns-locate).

Ken

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 16 Jul 2001 21:50:59 -0500

We are nearing the end of the last call for this document.  
I would like to hear from the authors on these comments. 

> It might be a good idea to mention and require ASN.1 DER encoding ...

I agree. 

> this would *require* the use of SPNEGO!

Does this really require SPNEGO, or just make it possible to use it?
Section 7. states SPNEGO [8] may be used to securely negotiate between 
the protocols. I don't see this requiring its use. It could be the client
and server must know in advance which mechanism to use, and don't try 
and negotiate.

--

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 16 Jul 2001 21:50:59 -0500

I agree. 

--

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 16 Jul 2001 21:50:59 -0500

I agree. 

--

---

From: Ken Raeburn <[email-masked]>
Date: 18 Jul 2001 18:17:50 -0400

> and server must know in advance which mechanism to use, and don't try 

I could be wrong, but I suspect it just encourages its use.  MIT's
Kerberos ftp/ftpd won't talk to another GSSAPI ftp/ftpd that doesn't
use the Kerberos mechanism; this seems like the same sort of deal.
It's just that if you implement everything in this draft, you've got
more than one mechanism, so you may need a way to choose or negotiate.
If MIT's GSSAPI implementation had a second mechanism, we'd have
exactly the same problem.

If the application protocol lets you try to initiate multiple times
with different GSSAPI mechanisms, that's pretty much the same as an
insecure negotiation, and should probably be discouraged, unless maybe
the second mechanism is SPNEGO.  But if it's allowed, it is a form of
negotiation....

Ken

---

From: Jonathan Trostle <[email-masked]>
Date: Wed, 18 Jul 2001 15:39:35 -0700

>> It might be a good idea to mention and require ASN.1 DER encoding ...

I will add the requirement for ASN.1 DER encoding.

>and server must know in advance which mechanism to use, and don't try 

That's right - SPNEGO is not required.

Jonathan

---

From: Jonathan Trostle <[email-masked]>
Date: Wed, 18 Jul 2001 16:10:33 -0700

>but I still think it'd be bad to require that.

I can add some words indicating that this is a potential problem (not
limited to iakerb) and discuss some countermeasures. For example, the KDC
port numbers can be statically configured on the proxies. Then a realm can
be assured that the proxies only forward messages to the KDC's.
Additionally, as mentioned below, the proxy can do some amount of
application level message inspection.

Another possibility is to use Kerberos in combination with DNS security
(TSIG) to protect the DNS exchanges. Note that the initial DNS SRV KDC
lookup by the proxy will be unprotected - but an attack here is at most a
DoS on the proxy.

Jonathan

---

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 19 Jul 2001 10:04:39 -0500

The WG last call for the draft-ietf-cat-iakerb-07.txt has now ended,
but I would like to extend it till Monday 7/23, to give the authors
time to comment on Ken Raeburn's note of 18 July 2001 18:17:50 -0400

There where three comments, and let me try and summarize them:

 (1) An IAKERB server which also used the krb-dns-locate facility 
     could allow an attacker to change DNS, and use the IAKERB server
     to attack other machines. 

 (2) The draft should say it will used DER.

 (3) The draft may lead one to imply the SPNEGO was required since it
     defined multiple mechanisms. 

Jonathan has addressed the above. He has said he will add comments
on how to avoid the attack in (1), add the DER is required in (2)
and that SPNEGO in not required. 

--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Jul 2001 14:00:33 -0400

Ok, so, IAKERB is, essentially, a KDC proxy? a KDC proxy running over
GSS-API? with IAKERB acting as a mechanism extension to the KerberosV
mechanism?

Why do this within GSS-API? Why not have a proxy external to GSS?

Or is there no benefit to KDC proxying unless the clients and servers
are talking GSS? And why would that be?

And why not just extend AP_REQ/AP_REP instead in RFC1510 if the proxying
is to occur over the client<->server conversation, rather than
client<->KDC?? Then no extensions would be needed to the Kerberos V GSS
mechanism RFC.

I must be missing something... What?

Nico

--

. 

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Jul 2001 20:37:00 +0200 (METDST)

> I must be missing something... What?

GSS-API requires only the minimal amount of "connectivity", i.e.
the "client"/initiator knows how to exchange information with
a "server"/acceptor in an application-specific fashion.

vanilla Kerberos on the other hand requires a fair amount of
direct IP connectivity and configuration to be present at
the "client"/initiator side before it can actually be used,
and that IP connectivity is required and used by Kerberos
"under the covers" for key managment (i.e. ticket acquisition).

"under the covers" because it happens totally outside of the
communication between the application "client" and application "server".

The idea behind IAKERB (as least the idea that Mike Swift conveyed
at the Los Angeles IETF) has *significant* merit.  Modifying
the rfc-1964 context establishment by itself fits just fine
into GSS-API.

However trying to make IAKERB look like independent gssapi mechanisms
as the current document does is a pretty bad idea.  Not only would
the spec require a lot of additional information how to mutilate
rfc-1964 messages, and when and where to emit which mechanism
OIDs at the API level,  the extension would be (and probably remain)
unusable for several existing *portable* gssapi based applications
as well as those gssapi-based applications that conciously select
a gssapi mechanism by OID or negotiate a gssapi mechanism via SPNEGO today,
simply because these applications don't know (and probably don't care)
under which situations IAKERB must be used and under which straight
rfc-1964 can be used.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 23 Jul 2001 15:19:10 -0400

> communication between the application "client" and application "server".

Yes, but under the covers of the API is one thing, and under the covers
of the protocol is another.

So I still don't see why a KDC proxy protocol external to GSS wouldn't
be better, particularly considering that it would be useful to non-GSS
users of Kerberos.

That said, locating a KDC proxy may not be easy, so putting the proxy
protocol within a GSS mechanism gains value by taking the proxy location
issue off the table (either the GSS acceptor can proxy and everything
works, or it can't proxy and Kerberos GSS doesn't work).

I'm mildly unconvinced.

I'd rather see similar extensions to the Kerberos AP_REQ/AP_REP messages
to achieve the same effect as IAKERB, but benefitting all users of
Kerberos, not just GSS. However, I suspect it would be hard to
transparently modify AP_REQ/AP_REP to add this proxy feature.

Sigh.

> the rfc-1964 context establishment by itself fits just fine

Yes, but see above.

> under which situations IAKERB must be used and under which straight

The problem seems to be "how to know that IAKERB may be the only workable
option."  If there is a solution to that problem, then a separate OID
makes sense, leaving IAKERB to be used specifically only when it may be
the only workable way to obtain the necessary service ticket. OTOH, one
OID should always work, provided that the Kerberos GSS mechanism
extensions are transparent, n'est ce pas?

Then again, using a separate OID allows IAKERB to be negotiated via
SPNEGO. I.,e., an app could offer to do IAKERB or PKI, but not Kerberos
(presumably due to a lack of KDC connectivity); without a separate OID
there's no way to convey the connectivity issue and, if the other side
does not support IAKERB then it may force the use of Kerberos only to
fail during the AP_REQ/AP_REP stage, whereas the preferred outcome would
be to have PKI selected.

All in all, it seems to me that using a different OID is a better
approach where SPNEGO is supported, and one OID is better where SPNEGO
is not. Is this assesment correct?

In any case, I can imagine that clients might end up preferring to fetch
service tickets via IAKERB, even when there is direct connectivity to
the relevant KDCs, simply because it's easier to program... I'm not
sure wether that's good, bad or neither.

Nico
--
. 
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

---

From: Martin Rex <[email-masked]>
Date: Mon, 23 Jul 2001 22:24:12 +0200 (METDST)

> be better, particularly considering that it would be useful to non-GSS

As Paul already mentioned: that would be a completely different
proposal -- not relevant for the current IAKERB discussion.
Feel free to write a different document for such a proposal.

> extensions are transparent, n'est ce pas?

Yup.
How to know that IAKERB may be the only workable option is an issue
local to the particular Kerberos gssapi mechanism.  The application
should not be bothered with it and should not have to care about it,
i.e. it should be a transparent extension.

> is not. Is this assesment correct?

I don't agree.

Even when the spec was using only the rfc-1964 OID, it would still
be possible for those who really feel a strong urge to write a
glue that simulated distinct gssapi mechanisms and mutilated *each*
token (context and per-message tokens) by replacing the mechanism
OID, effectively yielding the result of the current document.

This wouldn't force every Kerberos implementor to do so.
(Both schemes wouldn't be interoperable either -- but the current
proposal seems to care little about installed base and
interoperability anyway).

> sure wether that's good, bad or neither.

Some servers might not want to be blocked when accepting a
security context.  It is actually a pretty neat feature that
with traditional Kerberos accepting a security context
is a purely CPU-bound operation.

-Martin

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 24 Jul 2001 15:49:00 -0500

The WG last call for the draft-ietf-cat-iakerb-07.txt has now ended. It had
been extended from 7/18 to 7/23 in order to get a few more comments addressed
which cam in on the last day. 

 (3) The draft may lead one to imply the SPNEGO was required since it
     defined multiple mechanisms, and this could lead to other problems
     as well. 

I believe the additional comments over the weekend did not show that there
was a problem in the mechanism OIDs, or the that SPNEGO would be required. 

Jonathan had said he would address (1) and (2) with additional comments in the 
document.  Therefore the chair see that there is general consensus that this 
draft should proceed. 

When Jonathan submits a new draft with these minor changes, I will advance the 
draft. 

--

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Jul 2001 01:17:46 +0200 (METDST)

> was a problem in the mechanism OIDs, or the that SPNEGO would be required. 

I'm really disappointed.

I raised clear and obvious reasons why using distinct mechanism OIDs
is be a stupid idea since it clearly conflicts with gssapi architecture
and I haven't seen any *real* benefit using seperate OIDs could have
(the "secure" negotiation is a non-reason, this can be obviously
 achieved in the exact same fashion inside rfc-1964 tokens).

Besides these problems, the document *is* underspecified:

  - since it extends rfc-1964 it must specify how which mechanism
    OIDs are going to be on which context-level and per-message
    token headers.

  - it fails to specify how the mechanism OID input and output
    parameters of the GSS-API calls
      gss_init_sec_context(),gss_accept_sec_context(),
      gss_inquire_sec_context(), gss_canonicalize_name()
    must be managed -- just passing along values from
    the underlying rfc-1964 Kerberos would clearly violate
    the GSS-API spec.

I personally consider it a major flaw that this proposal requires
SPNEGO for negotiation, whereas the significantly less complex
solution with the single rfc-1964 OID and negotiation within
the token would fly much nicer without the SPNEGO crap.

With such serious technical issues and no remedies the document
should *NOT* move an inch.

-Martin