Subject: FW: First wave of GSS testing results

From: "Linn, John" <[email-masked]>
Date: Tue, 17 Apr 2001 07:36:38 -0400

[This is a retransmission - I sent the original late last week and haven't
yet seen a list copy come back to my inbox.  Apologies if this is a repeat
for others. --jl]

>  -----Original Message-----
> From: 	Linn, John  
> Sent:	Friday, April 13, 2001 10:09 AM
> To:	CAT-WG List (E-mail)
> Subject:	First wave of GSS testing results
> 
> I've been pleased to see the messages recently posted to this list
> concerning several GSS-Java implementations and interoperability results
> using RFC-2853, as well as Martin Rex's announcement of the availability
> of his GSSTEST engine for RFC-2744.  Both Java and C results should be
> applicable, I expect, to the potential advancement of RFC-2743 to Draft
> Standard.  
> 
> Mayank indicated in his 2 April message that: "We've run simple tests and
> interoperated successfully 
> against C implementations of Solaris GSS-API, the latest MIT Kerberos
> release, and Windows 2000 SSPI. We've exercised context establishment with
> mutual authentication, delegation and confidentiality using Kerberos v5 as
> the underlying mechanism. The tests call wrap/unwrap and getMIC/verifyMIC
> for 
> per-message protection, and use delegated credentials to establish further
> contexts."
> 
> Martin indicated to me in off-list mail that several implementations have
> been tested against GSSTEST.  He identified the following areas in
> RFC-2743/2744 (summarized here by permission) which aren't tested by the
> package:
> 
>  - all context establishment is performed with the same set of
>    context flags (CONFIDENTIALITY+INTEGRITY+REPLAY+TRANS+MUTUAL),
>    so neither target-only nor anonymous authentication is tried/checked,
>    nor any other combination of message protection features
>  - channel_bindings are never tried/used
>  - presence/absence of prot_ready_flag while GSS_S_CONTINUE_NEEDED
>    is not analyzed or recorded, nor what and how many message protection
>    operations are possible at that stage for both initiator and acceptor 
>  - gss_add_cred() is not used 
>  - the oidset* series of calls is not looked at
>  - delegated credentials
> 
> Mayank's summary indicates at least one tested example of delegated
> credentials.  I'd like at this point to solicit further comments on
> interoperability results, especially if/as they demonstrate interoperable
> use of additional features.  The requirements for Draft Standard
> advancement (RFC-2026, sec. 4.1.2) state that: "The requirement for at
> least two independent and interoperable implementations applies to all of
> the options and features of the specification. In cases in which one or
> more options or features have not been demonstrated in at least two
> interoperable implementations, the specification may advance to the Draft
> Standard level only if those options or features are removed."  The
> broader that test coverage can be substantiated, the less likely it'll be
> that we'll have to investigate how to selectively remove elements from the
> specifications as a basis for advancing them. 
> 
> Thanks (in retrospect and in advance) for any and all inputs to this
> discussion.
> 
> --jl
> 
> 
> 
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: "Linn, John" <[email-masked]>
Date: Tue, 24 Apr 2001 15:13:06 -0400

CAT fanciers:

My apologies if you've already seen this message; some list redistribution
problems were causing erratic delivery over the last week or so, and it's
possible that the previous sends may have reached some but not all
addressees.  If you've sent recent messages to the CAT-WG list and haven't
seen copies returned (and/or if you don't see your messages in the archive
at ftp://ftp.ietf.org/ietf-mail-archive/cat/current), you may want to resend
them to the list.  

Thanks, ...

--jl